bunk at kernel
Sep 17, 2008, 3:12 AM
Post #10 of 10
On Wed, Sep 17, 2008 at 01:04:23PM +0300, Kirill A. Shutemov wrote:
Re: [PATCH] linux/inotify.h: do not include <linux/fcntl.h> in userspace
[In reply to]
> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/