Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 31 Mar 2022 14:47:19 -0400
From: Rich Felker <>
To: 王洪亮 <>
Subject: Re: Re: add loongarch64 port

On Thu, Mar 31, 2022 at 02:20:51PM +0800, 王洪亮 wrote:
> 在 2022/3/29 下午4:26, Arnd Bergmann 写道:
> >On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 <> wrote:
> >>Hi,
> >>
> >>we have published 0001-add-loongarch64-port-v2.patch in
> >>
> >>
> >>
> >>The patch v2 fixed the issues pointed out in v1.
> >>
> >>have any other issues to modify?
> >I see you still refer to the system calls that I asked to be removed from
> >the kernel: clone() and the old stat() family (pre-statx). Please use
> >only the system calls that are actually supported in mainline kernels,
> >otherwise it does not work.
> Hi,  Arnd
> I understand the new system call is clone3() ?
> I found musl does not support the clone3() call now, I can implement the
> clone3() in LoongArch for future called.

The point isn't that there should be a clone3() function (there
shouldn't) but that __clone has to be implemented by making the
__NR_clone3 syscall not the (nonexistant) __NR_clone syscall.

> 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
> >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,

I don't think we have generics for all of these yet, and what some of
them should be is not clear -- for example, generic kstat should
probably match the statx structure on 32-bit archs. I actually need to
figure some of this out as part of merging the rv32 port. So, for now,
it's probably ok for the loongarch64 port to keep its own copies of
the ones that don't yet have generics, and leave deduplication as
separate task to be done later.

However, for struct stat (musl userspace), I think it would be nice to
use a definition that matches the intended "generic" one (the one
riscv64 and aarch64 use).


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.