From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5868 invoked by alias); 5 Dec 2018 19:53:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 5856 invoked by uid 89); 5 Dec 2018 19:53:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=inclusion, worried, irrespective, mixing X-HELO: mx1.redhat.com From: Florian Weimer To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] Linux: Implement membarrier function References: <8736rldyzm.fsf@oldenburg.str.redhat.com> <98842c25-ec63-b793-08b3-539c32a9922a@linaro.org> <87y394gh6p.fsf@oldenburg2.str.redhat.com> <87r2evg7xx.fsf@oldenburg2.str.redhat.com> <559cf582-d460-dbc1-251f-cda957c9e7bf@linaro.org> Date: Wed, 05 Dec 2018 19:53:00 -0000 In-Reply-To: <559cf582-d460-dbc1-251f-cda957c9e7bf@linaro.org> (Adhemerval Zanella's message of "Wed, 5 Dec 2018 17:15:24 -0200") Message-ID: <8736rbg385.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-12/txt/msg00177.txt.bz2 * Adhemerval Zanella: > 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 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? I will try to find it. > 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 think that's not actually true. We only need to do this if we need newer definitions for building glibc itself (including the test suite). >> 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. I'm not too worried about this for new headers with a dedicated purpose. Using the UAPI will actually make things work in more cases; see below. > - 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. Well, that already happens with the duplicated header approach if users want to use UAPI headers, too. It requires complicated synchronization to make it work. We can tweak the conditional for the header inclusion further, like this: +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 16, 0) \ + || __glibc_has_include () \ +# include +#else With GCC 5 and later, this would always prefer the kernel header if available. There would never be a conflict between the definitions, irrespective of header file inclusion order. What do you think? Thanks, Florian