From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14941 invoked from network); 31 Mar 2022 18:47:35 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2022 18:47:35 -0000 Received: (qmail 30387 invoked by uid 550); 31 Mar 2022 18:47:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30348 invoked from network); 31 Mar 2022 18:47:32 -0000 Date: Thu, 31 Mar 2022 14:47:19 -0400 From: Rich Felker To: =?utf-8?B?546L5rSq5Lqu?= Cc: musl@lists.openwall.com Message-ID: <20220331184719.GH7074@brightrain.aerifal.cx> References: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 > >> > >>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