[klibc] [PATCH] linux/inotify.h: do not include <linux/fcntl.h> in userspace
bunk at kernel.org
Wed Sep 17 03:12:02 PDT 2008
On Wed, Sep 17, 2008 at 01:04:23PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 17, 2008 at 12:32:40PM +0300, Kirill A. Shutemov wrote:
> > On Tue, Sep 16, 2008 at 07:09:02PM +0300, Adrian Bunk wrote:
> > > On Tue, Sep 16, 2008 at 07:10:25AM -0700, Ulrich Drepper wrote:
> > > > Kirill A. Shutemov wrote:
> > > > >> What is the error message?
> > > > >
> > > > > /usr/include/asm-generic/fcntl.h:117: error: redefinition of 'struct
> > > > > flock'
> > > >
> > > > And? None of these programs should use <linux/inotify.h>. There has
> > > > for the longest time been a <sys/inotify.h> header which doesn't need
> > > > any kernel headers. In fact, <linux/inotify.h> should not be exported.
> > >
> > > Even if userspace applications shouldn't use it directly this doesn't
> > > sound right:
> > >
> > > We shouldn't force all libc implementations to copy the contents into a
> > > private header.
> > glibc and dietlibc provide <sys/inotify.h>. newlib and uclibc don't. klibc
> > provides <sys/inotify.h> but it depends on <linux/inotify.h>
> Oh.. Sorry. uclibc provides <sys/inotify.h>.
> So unexporting <linux/inotify.h> breaks only klibc.
klibc is actually doing the right thing.
The userspace kernel headers situation used to be a complete mess, and
it is therefore understandable that some libc implementations are
currently not using <linux/inotify.h>, but ideally in the long term all
libc implementations should use <linux/inotify.h>.
Whether, and if yes when, libc implementations starts using
<linux/inotify.h> is not our business, but we have to ensure that it
works for the libc implementations that do use it.
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
More information about the klibc