This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __need macros for communication with compiler-provided headers


On 3/24/2017 7:55 AM, Zack Weinberg wrote:
On Thu, Mar 23, 2017 at 11:38 AM, Chris Metcalf <cmetcalf@mellanox.com> wrote:
On 3/22/2017 2:47 PM, Zack Weinberg wrote:
So my suggestion would be that you provide an uapi/arch/int_reg_t.h
(or something like that; it doesn't matter what the name is) that
_only_  defines int_reg_t (and names in the implementation namespace)
and then the glibc headers that need int_reg_t can include that.
You'll find, when you make this change, that arch/abi.h is suddenly
quite a bit tidier.

The catch though is that we do need a transition plan.  I suspect it's
not a big deal if old libc headers + new kernel headers start getting
_all_  of arch/abi.h from the small number of headers that use the
__need macro, so maybe it can be as simple as "as of version X.Y of
glibc we require version A.B.C or later kernel headers for Tile."

My concern is that we don't want to screw up the namespace for anything
that includes <bits/link.h> or <bits/setjmp.h> due to getting all of
<arch/abi.h>.

How does this change look to you?
I don't know enough about how these files are used outside of glibc to
do a full review, but that looks like it will work from our end.

I mailed out a patch to LKML and staged the change in linux-tile
to go in during the merge window for 4.12.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]