Re: [gamin] Re: [Patch 0.0.10] Cleanup ENABLE_DNOTIFY and HAVE_LINUX and fix build error [u]

[Daniel Veillard <veillard redhat com>]

On Fri, Sep 24, 2004 at 08:55:50AM -0400, John McCutchan wrote:
> On Fri, 2004-09-24 at 07:30, Daniel Veillard wrote:
> > On Fri, Sep 24, 2004 at 12:58:07PM +0200, Martin Schlemmer [c] wrote:
> > > On Fri, 2004-09-24 at 01:30 +0200, Martin Schlemmer wrote:
> > > > On Thu, 2004-09-23 at 19:17 -0400, Daniel Veillard wrote:
> > > > 
> > > > > > to do it. So if you are interested in working on it that would be
> > > > > > wicked! I can answer any questions you have about inotify.
> > > > > 
> > > > >   inotify relies on kernel support, this can be checked at runtime
> > > > > I think one of the best thing to do to get more inotify testing is to 
> > > > > get rid of the inotify configure option, always compile it in and make
> > > > > its init routine check at runtime, if not present then use dnotify.
> > > > > That way it's only a kernel option, and users/testers are quite more
> > > > > familiar to installing and booting a new kernel than replacing a 
> > > > > component of their infrastructure after having recompiled it with a different
> > > > > option. 
> > > > > 
> > > > 
> > > > Will work for me - then I can drop some magic I have to do.  Possible
> > > > problem though, is that you need inotify.h.  One solution is to check
> > > > if we can include it, but seeing that many out there will not have
> > > > it in /usr/include/linux, and using current kernel sources have sticky
> > > > issues, I do not know if that is such a good idea.  The other possible
> > > > solution is to ship our own, and use that if it is not
> > > > in /usr/include ... ?  Then you can enable it for the same checks as
> > > > dnotify.  
> > > > 
> > > 
> > > How about attached patch?
> > 
> >   I think it boils down to how stable the existing kernel API is.
> > John, do you think it's a mistake to have a local copy of the inotify
> > header until we get it from the shipped kernel versions ?
> 
> 
> The kernel API is reasonably stable. It is fine to keep a copy of the
> header in the source tree until it is shipped with a kernel. I will make
> sure that any changes get pushed in to gamin.

   Okay, I applied Martin Schlemmer patch and commited the new version,
in case the kernel interface changes so radically that user level compiled
against the previous version don't work, changing the kernel I/O file would
allow a clean versionning, and client stuff would fallback to dnotify backend.
This looks clean to me.

     excellent !

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/