Scott James Remnant wrote: > On Sat, 2009-06-06 at 10:01 -0700, Bryan Kadzban wrote: > >> Below is a patch to emulate <sys/signalfd.h> and <sys/inotify.h> if >> those headers don't exist at configure time (via inline functions that >> use syscall() directly). It has to pull __NR_xxx (for the various xxx >> syscalls) from the kernel includes, which are per-arch, so there are a >> few new configure.ac tests to find the appropriate arch. This takes a >> while, but isn't run if both <sys/signalfd.h> and <sys/inotify.h> are >> present. > > For upstart, I made a deliberate decision not to do this anymore; if you > want to use an up-to-date set of plumbing tools, you should at least > update your glibc ;) (my opinion, at least) There are two issues with this that I can think of. First is that the only glibc versions that support signalfd are not that old; the older they were, the less I'd complain. :-) Second is that I'm fairly sure upgrading glibc requires a recompile of basically the entire rest of the system. For the same reason that you can't dump a new kernel's headers in /usr/include/linux at will: in that case the (new) structure sizes won't match what the (old) syscall wrappers in glibc are sending to the kernel when invoking the (old) syscalls when new programs are compiled. In this case, the new glibc will be calling the new syscalls using the new kernel headers, and new structures; this works great for newly-compiled programs. But every existing binary on the system was built against the older structures, so the syscall wrapper will call the wrong thing for them. When glibc's foo(2) wrapper calls syscall(__NR_foo, foo), which expects a pointer to "struct foo", but the new glibc's foo(2) wrapper calls into syscall(__NR_foo2, foo2) instead, which expects a pointer to "struct foo2" which has more members, current programs all break. (Though I know glibc does weird stuff with symbol versioning: if that also means they keep the "old" foo(2) wrapper around when a newer glibc is compiled, then this argument is mostly wrong. But I don't believe they do this; I don't see multiple mount(2) wrappers, for instance.) And I'd rather not spend a week rebuilding everything when I can spend a couple hours writing this patch... -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
