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=-2.1 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 17617 invoked from network); 17 Feb 2023 07:06:55 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2023 07:06:55 -0000 Received: (qmail 7240 invoked by uid 550); 17 Feb 2023 07:06:51 -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 7208 invoked from network); 17 Feb 2023 07:06:50 -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> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: <2775a5e6-1fc0-e542-47ea-e90170053654@loongson.cn> Date: Fri, 17 Feb 2023 15:06:35 +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: <20230216231336.GW4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8AxHuR7J+9j2iE1AA--.61875S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoWxXFy3Cw1Utr4kZF18Ar4rGrg_yoW5Jw1DpF WFya1jyF4Dtr1Skw1vvw18urWIyw1UtFs8Xrn8Wry8u3s8ta4Sqr1SqrsI9as0qw4I9F12 vrW5W3WfKFWDAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bI8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l 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 上午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