[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220331184719.GH7074@brightrain.aerifal.cx>
Date: Thu, 31 Mar 2022 14:47:19 -0400
From: Rich Felker <dalias@...c.org>
To: 王洪亮 <wanghongliang@...ngson.cn>
Cc: musl@...ts.openwall.com
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 王洪亮 <wanghongliang@...ngson.cn> wrote:
> >>Hi,
> >>
> >>we have published 0001-add-loongarch64-port-v2.patch in
> >>
> >>https://github.com/loongson/musl/tree/loongarch-v1.0.
> >>
> >>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).
Rich
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.
