From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willem de Bruijn Subject: Re: [PATCH v06 18/36] uapi linux/errqueue.h: include linux/time.h in user space Date: Sun, 6 Aug 2017 17:24:20 -0400 Message-ID: References: <20170806164428.2273-1-mikko.rapeli@iki.fi> <20170806164428.2273-19-mikko.rapeli@iki.fi> <20170806205654.GF28459@lakka.kapsi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20170806205654.GF28459-dqH1CgrzRhOk/eJAJmRu5A@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mikko Rapeli Cc: LKML , Linux API , Willem de Bruijn , Soheil Hassas Yeganeh , Network Development List-Id: linux-api@vger.kernel.org >> > +#ifdef __KERNEL__ >> > +#include >> > +#else >> > +#include >> > +#endif /* __KERNEL__ */ >> >> This will break applications that include manually. >> I previously sent a patch to use libc-compat to make compilation succeed >> when both are included in the case where is included after >> . >> >> https://lkml.org/lkml/2016/9/12/872 >> >> The inverse will require changes to the libc header to avoid redefining >> symbols already defined by >> >> The second patch in that 2-patch set included >> unconditionally after the fix. This broke builds that also included >> in the wrong order. I did not resubmit the first patch as a >> stand-alone, as it is not sufficient to avoid breakage. > > I wasn't aware of your change, but I was about to send this to fix the > case when glibc is included before : > > https://github.com/mcfrisk/linux/commit/f3952a27b8a21c6478d26e6246055383483f6a66 There are a few differences between the two. Including does not unconditionally define all the symbols. Some are conditional on additional state, such as __timespec_defined. > but you also ran into problems where is included before > which need fixes in libc header side. > > So how to proceed with these? The libc-compat change is a good fix that can be submitted on its own. > I don't like leaving a few dozen non-compiling header files into uapi. I agree, but I do not see a simple solution. Unless libc has the analogous change, including either or in userspace can unfortunately cause breakage. The added include if __KERNEL__ is defined should be safe, though.