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=-4.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 3681 invoked from network); 31 Mar 2022 08:14:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2022 08:14:43 -0000 Received: (qmail 17940 invoked by uid 550); 31 Mar 2022 08:14:40 -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 17902 invoked from network); 31 Mar 2022 08:14:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648714466; bh=xjW+tP7FGrgz+t/7eoE0t0A1PTlvVdgQdrip688iszM=; h=References:In-Reply-To:From:Date:Subject:To:From; b=fl8go3k+ww+D6oDH7FWpx1fvtr9Il/4CLV5mSP3eTZfEKJU8cyyDK7dFzeMPcuohY vDvX/sjtj7xBlp2PYm0NTsYmTFujuk56FpNaFuabsaVlyWu/uc0F9VuUWYCKk3RQXN DLbZhvSQe2D52ySVB+gIfOR84gLzNr+kgVjInBPYUIexX9ONjO/URx9tWPWzkddazv FOf8hH6dDLSmK57unDrMkliZLGZUcXLglbhEXmpmBwQarWZgAYadQXhq7UJ/D9h9ng HiX0KE+Ipnz1rDcnz0K43GlVJ3UOII1NUHbq1kT3Kst5hOb4JrArMAP7BqTRwYdKH5 Jhqe0l/OCTqwQ== X-Gm-Message-State: AOAM532HpUO8PAA3VVWPVi/0IDZ2PbJKA0dYuqs6Ii6/qV/7ghn2eOUN tapuEBEI3pPvaMx20ZbWXBmXKCtj/51jaoXcHm8= X-Google-Smtp-Source: ABdhPJxNx/wwzDld7NWJSZX0XmqEzdpYZPXfNNDyaALlsTCd6uDTMntlLpp7jSMfNYIXKvut8TZNoo2+pU55LXqFoRc= X-Received: by 2002:a5d:6505:0:b0:205:9a98:e184 with SMTP id x5-20020a5d6505000000b002059a98e184mr2998172wru.317.1648714464991; Thu, 31 Mar 2022 01:14:24 -0700 (PDT) MIME-Version: 1.0 References: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn> In-Reply-To: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn> From: Arnd Bergmann Date: Thu, 31 Mar 2022 10:14:08 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Re: add loongarch64 port On Thu, Mar 31, 2022 at 8:21 AM =E7=8E=8B=E6=B4=AA=E4=BA=AE wrote: > =E5=9C=A8 2022/3/29 =E4=B8=8B=E5=8D=884:26, Arnd Bergmann =E5=86=99=E9=81= =93: > > On Tue, Mar 29, 2022 at 10:12 AM =E7=8E=8B=E6=B4=AA=E4=BA=AE 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 propose= d 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-indep= endent > > 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