I'm trying to code a small app that will be using inotify to watch events on files. Inotify has been a part of gentoo-dev-sources and now gentoo-sources for quite a while. However the current associated linux-headers (sys-kernel/linux-headers-2.6.8.1-r2 on x86) is not patched with inotify, forcing me to either : - include my own inotify.h which is bad in case the API changes (this has happened just a few weeks ago) - include the inotify.h from /usr/src/linux/include/linux/inotify.h, which is bad too (cdrecord did this, and we all know how it ended) Is this doable simply or would it require massive changes? Reproducible: Always Steps to Reproduce: Expected Results: Kernel headers should match the current kernel (patch-wise) sys-kernel/gentoo-sources-2.6.11-r9 sys-kernel/linux-headers-2.6.8.1-r2
The headers follow the vanilla-sources release. I don't believe the inotify patch is included with the vanilla kernel.
Yes, inotify is a patch added into gentoo-sources by the kernel team. However I don't know anyone on gentoo using vanilla-sources, and the gentoo handbook advises you to use gentoo-sources. Wouldn't that make sense to have corresponding headers? Or something completely crazy : have a set of headers for every *-sources ? (I'm just asking :)
I am not a Gentoo developer, but my guess would be, it follows the vanilla sources because all the other sources are based upon it. If it installed inotify.h from the gentoo sources, it wouldn't help people who use mm-sources which includes a different version of inotify (as an example).
Include your own inotify.h and fall-back to it if you can't find inotify.h in the usual include places. This is how other apps do it. Yes, inotify is an unstable API and you *will* encounter API/ABI compatibility problems regardless of which header file you use.
As of linux 2.6.13-rc3, inotify is now part of the official vanilla sources. http://www.kernel.org/pub/linux/kernel/people/rml/inotify/MERGED Unfortunately, bumping linux-headers is an issue discussed in bug #100703 and currently the reason for a package.mask. So this bug should probably depend on 100703, but I'm not powerful enough to set dependencies. It could even be considered a dup, as inotify is mentioned there as well.
