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 26826 invoked from network); 12 Apr 2022 01:11:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Apr 2022 01:11:51 -0000 Received: (qmail 15664 invoked by uid 550); 12 Apr 2022 01:11:47 -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 15632 invoked from network); 12 Apr 2022 01:11:47 -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> Cc: Christian Brauner From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: Date: Tue, 12 Apr 2022 09:11:29 +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:AQAAf9Dx7xDB0VRicakfAA--.10022S3 X-Coremail-Antispam: 1UD129KBjvJXoW7ZFW8CrW8ArWfWw4fGry5CFg_yoW8WFy7pa yavFykKFs8JF4Igr42v3WIqF1FyFsxGr4rZr95tw1rA390vF1ftrW0kay3uayjvw48Cw1j vFW5Xry3ZrZ8Aw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv2b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y 6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa 7IU8pnQUUUUUU== X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] Re: add loongarch64 port 在 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.