Re: [musl] Re: add loongarch64 port

[王洪亮 <wanghongliang@loongson.cn>]

在 2022/3/31 下午4:14, Arnd Bergmann 写道:
> On Thu, Mar 31, 2022 at 8:21 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
>>> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> I do not understand what is old stat() family (pre-statx) ?  what is new ?
>>
>> I compare the system call  that related the stat  in musl and mainline
>> kernel 5.17,
>>
>> they are consistent.
>>
>> #define __NR3264_statfs     43            /*sys_statfs*/
>> #define __NR3264_fstatfs    44           /*sys_fstatfs*/
>> #define __NR3264_fstatat   79          /*sys_newfstatat*/
>> #define __NR3264_fstat      80            /*sys_newfstat*/
>> #define __NR_statx             291           /*sys_statx*/
>> #define __NR_statfs                 __NR3264_statfs
>> #define __NR_fstatfs               __NR3264_fstatfs
>> #define __NR_newfstatat      __NR3264_fstatat
>> #define __NR_fstat                 __NR3264_fstat
> The __NR_fstat and __NR_newfstatat  symbols are only defined by
> the kernel if  __ARCH_WANT_NEW_STAT is set, which should not be
> by the time the kernel port is merged. Instead, user space should
> call statx() here, which continues to be supported as a superset.
>
> The statfs/fstatfs  system calls are unrelated and can be used, the proposed
> fsinfo() system call that was meant as a replacement has never made
> it in
>
>>> For the signal list, the stdint.h header, and the 'struct stat' and
>>> 'struct kstat'
>>> definitions, I would expect that there is already an architecture-independent
>>> definition in musl that you can use, as these should be the same for
>>> all new architectures.
>> I understand the meaning is  define signal.h, stdint.h, struct stat and
>> struct kstat in generic,
>>
>> LoongArch use the generic definition.
>>
>> can we deal with this issue separately ?
>>
>> 1.LoongArch port based on the existing software framework in musl.
>>
>> 2.implement the generic definitions in musl, LoongArch use the
>>
>> architecture-independent definition.
> Yes, that works for me, I only care about the ABI issues: we have to
> ensure that the kernel interfaces in the upstream musl port are
> the same ones that are used in the upstream kernel port, to avoid
> breaking applications built on these after everything is upstream.
> (We can break compatibility with existing non-upstream user space
> for the moment, which is the point of this review).
>
> Any implementation details within musl that do not impact the ABI
> can come later. I mainly pointed out these three because I expected
> them to already have generic code in musl, given that the kernel does
> not require architecture specific definitions for these. If you have custom
> definitions, that introduces a certain risk that these correspond to an
> earlier private kernel version of yours rather than what will become
> the official port.
>
>        Arnd

Hi, Arnd


In kernel port, loongarch64 use the generic struct stat.

loongarch64 define struct stat and kstat in musl is consistent with

generic stat in kernel.


Hongliang Wang