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, NICE_REPLY_A,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 21970 invoked from network); 1 Apr 2022 07:40:35 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Apr 2022 07:40:35 -0000 Received: (qmail 20243 invoked by uid 550); 1 Apr 2022 07:40:32 -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 20202 invoked from network); 1 Apr 2022 07:40:32 -0000 To: musl@lists.openwall.com References: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: <34029768-603c-79a1-03c7-a02132a108ba@loongson.cn> Date: Fri, 1 Apr 2022 15:40:17 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf9Dx_xNhrEZiXJIUAA--.23212S3 X-Coremail-Antispam: 1UD129KBjvJXoWxXFW8KFyUGFW3KF1fGrW3Jrb_yoW5AFW5pa y3KFyYka1DJF13Gw10qwn5ZFyIyws3J3y3Gr98K348Aa45Xw1rKry8trWF9r15A395KF1j vw4vvwnrWF4UArDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG8wCY 02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8 v_M3UUUUU== X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] Re: add loongarch64 port 在 2022/3/31 下午4:14, Arnd Bergmann 写道: > On Thu, Mar 31, 2022 at 8:21 AM 王洪亮 wrote: >> 在 2022/3/29 下午4:26, Arnd Bergmann 写道: >>> On Tue, Mar 29, 2022 at 10:12 AM 王洪亮 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