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 1891 invoked from network); 2 Apr 2022 09:53:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Apr 2022 09:53:59 -0000 Received: (qmail 14184 invoked by uid 550); 2 Apr 2022 09:53:56 -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 14144 invoked from network); 2 Apr 2022 09:53:55 -0000 To: musl@lists.openwall.com References: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn> <34029768-603c-79a1-03c7-a02132a108ba@loongson.cn> <262e237c-7876-75ff-a6d5-bbc9cc6611b9@loongson.cn> <20220402072138.GI7074@brightrain.aerifal.cx> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: Date: Sat, 2 Apr 2022 17:53:41 +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: <20220402072138.GI7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf9DxbxMlHUhiKtAVAA--.24733S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Ar1rAr1xZw4UGFy3Jw4fKrg_yoW8WFykpF WYkay0ka1DAw13Cws7K3yY9a4Fyw1fJr43WwnxG3yrCrn0yry7Xry2qanruFy2vas7Wr1j vr1Fq3429a1DAa7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWU XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AK xVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07 jOb18UUUUU= X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] Re: add loongarch64 port 在 2022/4/2 下午3:21, Rich Felker 写道: > On Sat, Apr 02, 2022 at 02:19:44PM +0800, 王洪亮 wrote: >> Hi, Arnd >> >> I found it has not been removed from system call list in kernel yet. >> I wonder if I could keep consistent with the current status of the kernel >> for the time being,and modify as the kernel changes. > As I understand it, no -- musl targets the permanent kernel syscall > API/ABI for the arch. So if the legacy stat syscall is not going to be > part of the interface that's approved upstream in the kernel for this > arch, musl can't be using it. > > Am I correct in understanding that the syscall & struct stat that are > "there now" are part of a proposed port that's not yet upstream, and > that upstream maintainers are asking for them to be removed as part of > accepting the port? > Hi, Rich yes, but it has not been removed from kernel port yet,the Author hopes to keep it,so I consider modify it when the issue comes to a conclusion. Hongliang Wang >> 在 2022/4/1 下午3:48, Arnd Bergmann 写道: >>> On Fri, Apr 1, 2022 at 9:40 AM 王洪亮 wrote: >>>> 在 2022/3/31 下午4:14, Arnd Bergmann 写道: >>>> >>>> In kernel port, loongarch64 use the generic struct stat. >>>> >>>> loongarch64 define struct stat and kstat in musl is consistent with >>>> >>>> generic stat in kernel. >>> My point was that I asked for these to be removed in >>> >>> https://lore.kernel.org/lkml/CAK8P3a2kroHVN3fTabuFVMz08SXytz-SC8X11BxxszsUCksJ4g@mail.gmail.com/ >>> >>> With __NR_newfstatat and __NR_fstat gone from the system >>> call list, there is no 'struct stat' that is exposed by the kernel. >>> >>> Arnd