| |||||||||||||
Keeping up with the Kroah-Hartmans (who upgrade without notice)Keeping up with the Kroah-Hartmans (who upgrade without notice)Posted Aug 3, 2006 21:19 UTC (Thu) by wilck (subscriber, #29844)In reply to: Keeping up with the Kroah-Hartmans (who upgrade without notice) by xoddam Parent article: New kernels and old distributions
This means that Linus' policy against messing with userspace interfaces cannot meaningfully apply to sysfs, any more than to kmem. There is a huge difference between sysfs and /dev/kmem. sysfs is globally visible and has a lot of reasonable uses. For example, there are lots of tunables in sysfs that are outside the scope of udev and HAL but useful for other system applications. /dev/kmem, on the other hand, is usually only accessible to root, and useful only for kernel debugging. But the converse obligation, that the latest kernel should support old versions of udev and HAL, imposes *exactly* the 'stable API nonsense' that the kernel developers have declared utterly unacceptable. Perhaps the opposite is true - perhaps the 'stable API' is a more complex subject than Greg and his followers pretend? Perhaps it is not such total nonsense, after all? The discussion between Greg and Andrew is interesting in that respect: it appears that Andrew considers user space breakage more 'utterly unacceptable' than the restrictions on development progress caused by the stable sysfs API.
(Log in to post comments)
Keeping up with the Kroah-Hartmans (who upgrade without notice) Posted Aug 4, 2006 4:33 UTC (Fri) by xoddam (subscriber, #2322) [Link] > There is a huge difference between sysfs and /dev/kmem.> sysfs is globally visible and has a lot of reasonable uses. /dev/kmem used to have reasonable uses too, like insmod. Now insmod is done inside the kernel, and there are no reasonable uses left for it besides, as you say, debugging (but it is very limited even for that purpose). > Perhaps the opposite is true - perhaps the 'stable API' is a > more complex subject than Greg and his followers pretend? My point exactly -- on the one hand the 'no stable API' party wants to be able to change internals at will, maintaining a stable interface to userspace only, and on the other hand the primary spokesman for this party exposes internals to userspace in such a way that changing them *will* break userspace. I'm suggesting that the real boundary of the stable API is on the far side of userspace utilities like udev and modutils which *must* know about kernel internals. It's nice to *claim* a firm userspace/kernel boundary line, but maintaining that boundary will mean freezing interfaces to userspace technologies like hotplug in concrete from the very beginning. This is not reasonable. Hotplug is *required* for suspend; suspend was wrong; hotplug must change. The only alternative is to do *all* interesting hardware-related work in-kernel. Down with daemons!
|
|||||||||||||