From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 9EEC43858D39 for ; Mon, 3 Apr 2023 09:41:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9EEC43858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [10.20.4.187]) by gateway (Coremail) with SMTP id _____8AxJAxJnypkDAAWAA--.33755S3; Mon, 03 Apr 2023 17:41:29 +0800 (CST) Received: from [10.20.4.187] (unknown [10.20.4.187]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Cx8eRInypkyFoUAA--.53912S3; Mon, 03 Apr 2023 17:41:28 +0800 (CST) Subject: Re: [PATCH] LoongArch: Modify some member names in mcontext_t and ucontext_t structs to align them with the kernel. To: Xi Ruoyao , libc-alpha@sourceware.org Cc: adhemerval.zanella@linaro.org, Chenghua Xu , =?UTF-8?B?546L5rSq6JmO?= , lixing@loongson.cn, wuxiaotian@loongson.cn References: <20230324062510.1812367-1-caiyinyu@loongson.cn> From: caiyinyu Message-ID: Date: Mon, 3 Apr 2023 17:41:28 +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:AQAAf8Cx8eRInypkyFoUAA--.53912S3 X-CM-SenderInfo: 5fdl5xhq1xqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoW7uw4UAF4xCFWDAFW3uw1kuFg_yoW8AryxpF W5CF47Ca9rG343C3Z2yF9ruF4Sg395J345tFn8trW8Ar9IkF18trsrKw4Y9FZ3Zw13GF1j vF47KFy7Wa1qyaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bakYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_JrI_Jryl8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMxCIbckI1I0E14v26r1Y6r17 MI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67 AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0 cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z2 80aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIF yTuYvjxU25EfUUUUU X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 在 2023/4/3 下午5:25, Xi Ruoyao 写道: > On Mon, 2023-04-03 at 17:18 +0800, caiyinyu wrote: >> 在 2023/4/3 下午4:56, Xi Ruoyao 写道: >>> On Fri, 2023-03-31 at 11:52 +0800, caiyinyu wrote: >>> >>> /* snip */ >>> >>>> Your plan caused fails in glibc conform tests. >>> Let me try something... >>> >>>> We wanted to inform you that we are aware that the proposed >>>> modification[1] will affect the public API. However, since >>>> LoongArch >>>> Musl has not yet been released >>> Then why not change the Musl instead?  It's not released so you >>> won't >>> break existing code. >> This is also a viable solution, but we want to take advantage of the >> early development >> >> stage to standardize the member names of mcontext_t/sigcontext in musl >> and glibc2.36/37... >> >> to match those in the kernel in order to get rid of historical >> baggage, >> >> as mentioned in the previous email. > Give me several hours trying to make the anonymous union work. I see > similar things in other ports' mcontext_t definition so I guess I can > make it work... > > And please don't change Glibc 2.36/37. The reason is: > > If some downstream work decides get rid of historical things, the > maintainer can just say "Glibc < 2.38 is not supported". > > Or they can use #if __GLIBC_PREREQ (2, 38) to support both releases if > they want to support both old and new releases. > > But by backporting the change into 2.36 or 37, there will be no trivial > way to support both "old" definition and "new" definition because there > is no #ifdef can distinguish "patched" 2.37 and "unpatched" 2.37. And > you cannot tell distro maintainers to update there Glibc headers in > /usr/include because doing so is *very* dangerous. OK, thanks a lot.