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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28189 invoked from network); 17 Mar 2023 08:41:46 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Mar 2023 08:41:46 -0000 Received: (qmail 13594 invoked by uid 550); 17 Mar 2023 08:41:43 -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 13556 invoked from network); 17 Mar 2023 08:41:42 -0000 To: musl@lists.openwall.com References: <4fd8ad44-6e64-c4f3-6f48-420cdae8c13f@loongson.cn> <155e9a0c-5839-01a5-f152-888bcd918529@loongson.cn> <20230129170407.GL4163@brightrain.aerifal.cx> <7c77f6d5-7f42-f3a9-af81-99a251780d19@loongson.cn> <20230216231336.GW4163@brightrain.aerifal.cx> <2775a5e6-1fc0-e542-47ea-e90170053654@loongson.cn> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: <00d245b2-c0b5-9978-7f7b-9d5aa5df6137@loongson.cn> Date: Fri, 17 Mar 2023 16:41:26 +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: <2775a5e6-1fc0-e542-47ea-e90170053654@loongson.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8BxoOS2JxRkfXUDAA--.16072S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoWxArykJF4xZw1UXrW3AF4kCrg_yoW5XF1xpF WSya1jyF4Dtr1Skw1vvw18urWIyw17trs8Xrn5Gry8ur90qa4Sqr1FqrsI9FyDtws29F12 vr45W3WSgryDAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bI8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWxJVW8Jr1l84 ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVWxJr0_GcWl e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_ Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwI xGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcV C2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUzsqWUUUUU Subject: Re: [musl] add loongarch64 port v6. 在 2023/2/17 下午3:06, 王洪亮 写道: > > 在 2023/2/17 上午7:13, Rich Felker 写道: >> On Mon, Jan 30, 2023 at 09:27:21AM +0800, 王洪亮 wrote: >>> 在 2023/1/30 上午1:04, Rich Felker 写道: >>>> On Sun, Jan 29, 2023 at 03:52:18AM -0500, Ariadne Conill wrote: >>>>> Hi, >>>>> >>>>> On 2023-01-28 20:15, 王洪亮 wrote: >>>>>> Hi, >>>>>> >>>>>> Is there anything else that needs to be modified in patch v6? >>>>> It is likely that you will get a better review if you split up >>>>> the changes into logical ones and submit them to the list as >>>>> a group of patches. >>>> It's been a while since I looked in detail, but I don't think that's >>>> necessary here. It should just be a matter of ensuring that all >>>> previously requested changes were made, and that the ABI is >>>> official/stable on kernel and compiler sides. I've been away overseas >>>> (on vacation) for the past month and this kind of review is outside >>>> the scope of what I've been checking in on while away, but I will be >>>> back in roughly a week. >>>> >>>> Rich >>> Yes,this patch is modified according to the previous suggestions, >>> and the ABI is consistent with the kernel and compiler sides. >>> >>> I'm looking forward to your review and reply in a week.thanks. >> One thing that's come up since previous review is that we had things >> wrong around the kernel sigaction ABI on a number of archs. From the >> way you defined SA_RESTORER as 0, it looks like loongarch64 is >> intended not to have a restorer member in the kernel sigaction >> structure. Can you confirm? I think this means the ksigaction you're >> using in the musl port right now is wrong and mismatched with the >> kernel. If my understanding is right, once my patches for fixing the >> other archs are pushed, just removing the #define SA_RESTORER 0 line >> will make this correct. >> >> As long as the kernel has officially decided on adopting __NR_clone, >> it's fine (and preferable) to stick with using it for __clone. >> >> I still see a few places with whitespace issues here and there but I >> don't want to waste your time with them; I can clean them up in the >> diff before applying it. >> >> I also spotted some minor namespace details in bits/signal.h. I don't >> think this needs to block merge. I can prepare/propose a patch on top >> of the one adding the arch. >> >> So, really I think the only thing I need right now is to know whether >> my understanding of the SA_RESTORER situation is correct. >> >> Rich > Yes, your understanding is correct. I have confirmed that there is no > SA_RESTORER > define in loongarch64, so no sa_restorer member in kernel sigaction. > > Hongliang Wang Hi, Rich Do I need to do any other work with this patch v6？ Hongliang Wang