__need macros for communication with compiler-provided headers

[Chris Metcalf]

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