From: caiyinyu <caiyinyu@loongson.cn>
To: Xi Ruoyao <xry111@xry111.site>, libc-alpha@sourceware.org
Cc: adhemerval.zanella@linaro.org,
"Chenghua Xu" <xuchenghua@loongson.cn>,
王洪虎 <wanghonghu@loongson.cn>,
lixing@loongson.cn, wuxiaotian@loongson.cn
Subject: Re: [PATCH] LoongArch: Modify some member names in mcontext_t and ucontext_t structs to align them with the kernel.
Date: Mon, 3 Apr 2023 17:41:28 +0800 [thread overview]
Message-ID: <f2259f6a-430b-afe8-6f68-54f53c02f8a2@loongson.cn> (raw)
In-Reply-To: <d99eeda2442e61be7b8d0c6969d4d53e7b20da30.camel@xry111.site>
在 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.
next prev parent reply other threads:[~2023-04-03 9:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 6:25 caiyinyu
2023-03-24 7:00 ` Xi Ruoyao
2023-03-24 7:40 ` Xi Ruoyao
2023-03-31 3:52 ` caiyinyu
2023-04-03 2:52 ` caiyinyu
2023-04-03 8:56 ` Xi Ruoyao
2023-04-03 9:18 ` caiyinyu
2023-04-03 9:25 ` Xi Ruoyao
2023-04-03 9:41 ` caiyinyu [this message]
2023-04-03 10:12 ` Xi Ruoyao
2023-04-03 10:45 ` caiyinyu
2023-04-03 12:03 ` caiyinyu
2023-04-03 2:51 caiyinyu
2023-04-03 12:29 ` Adhemerval Zanella Netto
2023-04-03 12:33 ` caiyinyu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2259f6a-430b-afe8-6f68-54f53c02f8a2@loongson.cn \
--to=caiyinyu@loongson.cn \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=lixing@loongson.cn \
--cc=wanghonghu@loongson.cn \
--cc=wuxiaotian@loongson.cn \
--cc=xry111@xry111.site \
--cc=xuchenghua@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).