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=-5.8 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 4858 invoked from network); 13 Apr 2022 01:16:47 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Apr 2022 01:16:47 -0000 Received: (qmail 16245 invoked by uid 550); 13 Apr 2022 01:16:44 -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 16210 invoked from network); 13 Apr 2022 01:16:43 -0000 To: musl@lists.openwall.com References: <20220406160042.GB8499@voyager> <8dfcd620-4143-7450-8429-a89ed2264620@loongson.cn> <20220409131939.GK7074@brightrain.aerifal.cx> <20220409133044.GL7074@brightrain.aerifal.cx> <20220410152636.GM7074@brightrain.aerifal.cx> <20220411121100.GO7074@brightrain.aerifal.cx> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: <2ef8a9f1-f677-160b-5442-2057d505f906@loongson.cn> Date: Wed, 13 Apr 2022 09:16:30 +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:AQAAf9Dx7xNuJFZiqDIhAA--.12862S3 X-Coremail-Antispam: 1UD129KBjvJXoW7uw4kCF1fZr4rur1rWr48WFg_yoW8CF17pa ySyFyDKFs8JF4xGr12v3W0qFyYyrnrJr4rXr95try8Ar90vr1rtrW0va15uFyjvw48Gw1j vFW5Xry7Zr98Aw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv2b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j 6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa 7IU8v_M3UUUUU== X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] Re: add loongarch64 port 在 2022/4/12 上午9:11, 王洪亮 写道: > > 在 2022/4/11 下午9:01, Arnd Bergmann 写道: >> On Mon, Apr 11, 2022 at 2:11 PM Rich Felker wrote: >>> On Mon, Apr 11, 2022 at 10:03:13AM +0200, Arnd Bergmann wrote: >>>> On Sun, Apr 10, 2022 at 5:27 PM Rich Felker wrote: >>>>> On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote: >>>>>> On Sat, Apr 9, 2022 at 3:31 PM Rich Felker wrote: >>>>>>> Actually, if there aren't yet archs lacking SYS_clone, this API >>>>>>> regression may be a good argument not to drop SYS_clone on new >>>>>>> archs >>>>>>> yet until there's a way for new archs to get the same behavior >>>>>>> (unspecified stack size). >>>>>> That is a good point, but it also appears that the behavior of >>>>>> clone3() is unintentional >>>>>> here, I'm fairly sure it was meant to be a drop-in replacement >>>>>> for clone() with >>>>>> additional features. >>>>>> >>>>>> Not sure what the best fix for this is, as the check for size==0 >>>>>> was clearly >>>>>> intentional, but seems to prevent this from working. A special >>>>>> flag to ignore >>>>>> the size, or a magic size value like -1ull might work, but >>>>>> neither of them >>>>>> is a great interface. >>>>> Are there archs already affected, or will this one be the first? >>>> We have not added any other architectures since clone3 got added, >>>> so this is the first one. >>> In that case I really think __NR_clone should just be kept for now. It >>> doesn't really cost anything on the kernel side and it avoids a >>> dependency on working out how __NR_clone3 is going to fix the missing >>> functionality. >> Yes, fair enough. >> >>          Arnd > > > Do I need to implement __clone3 for future called in LoongArch port ? > > > Hongliang Wang. Hi, Have any other issues to modify in LoongArch port ? Hongliang wang