From: Xi Ruoyao <xry111@xry111.site>
To: caiyinyu <caiyinyu@loongson.cn>, libc-alpha@sourceware.org
Cc: adhemerval.zanella@linaro.org,
"Chenghua Xu" <xuchenghua@loongson.cn>,
王洪虎 <wanghonghu@loongson.cn>,
lixing@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, 03 Apr 2023 17:25:52 +0800 [thread overview]
Message-ID: <d99eeda2442e61be7b8d0c6969d4d53e7b20da30.camel@xry111.site> (raw)
In-Reply-To: <fdeee5ef-2abf-fd7a-aae9-67dacfcf4657@loongson.cn>
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.
>
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
next prev parent reply other threads:[~2023-04-03 9:25 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 [this message]
2023-04-03 9:41 ` caiyinyu
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=d99eeda2442e61be7b8d0c6969d4d53e7b20da30.camel@xry111.site \
--to=xry111@xry111.site \
--cc=adhemerval.zanella@linaro.org \
--cc=caiyinyu@loongson.cn \
--cc=libc-alpha@sourceware.org \
--cc=lixing@loongson.cn \
--cc=wanghonghu@loongson.cn \
--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).