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: [PATCH] Linux: Implement membarrier function



On 05/12/2018 16:11, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 05/12/2018 12:51, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> If we are replicating the values, meaning the idea is to keep it sync at least
>>>> when we have the minimum supported kernel of 4.16, why just not add a comment
>>>> to add linux/membarrier.h once the minimum supported kernel provides this
>>>> header and not rely on linux/membarrier.h?
>>>
>>> This way, we can compile the test with any supported kernel headers for
>>> glibc.
>>>
>>> If we defer to <linux/membarrier.h> unconditionally, we cannot build the
>>> test with all kernel headers.  The current approach definitely makes the
>>> test case much cleaner.
>>>
>>
>> My point is exactly to *not* rely on kernel headers.
> 
> I thought there was a general desire to move in the opposite direction,
> avoiding copying declarations and definitions in clean/new headers that
> are dedicated to a specific purpose?

I don't recall this discussion, do you have the link? In any case I still
think mixing header inclusion with the definition duplication is just
a double effort, it will still require syncing the definitions on each
kernel release.

> 
> I don't think we can add much value by copying the contents of those
> headers.  We can even relax the version check if we use __has_include
> (which has to be remain optional in installed headers, of course).
This example give us why trying to relying in kernel header to provide
glibc exported interfaces are at least tricky, imho.  The issues I can
think of are:

  - The header would require to be include safe in all possible releases
    and for all possible permutations, which means if something is broken 
    we need to rely on kernel to actually fix it.

  - glibc might provide different semantic to users depending of the
    underlying installed kernel header version.  It means for two
    identical glibc versions, some programs might fail to build 
    depending of the installed kernel version.


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