Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
Nested class devices and the future of the device modelNested class devices and the future of the device modelPosted Oct 20, 2005 15:57 UTC (Thu) by kleptog (subscriber, #1183)Parent article: Nested class devices and the future of the device model
You know, this is one of those moments where I *really* wish there was an unstable branch on the Linux kernel that had this kind of development. I'm reading emails on the Debian lists about packages like udev and hotplug that imply basically they work with versions 2.6.8 to 2.6.12 but after that you need something else and it looks like they're going to change it again...
This makes me very wary upgrading to 2.6 (I'm still on 2.4.27) since I *really* don't want to spend ages getting my module loading sorted out. I spent long enough getting it working here, I'm not just going to throw it all to the wind to see if it works.
So here's me asking: when do we get a stable kernel with a compatable userspace all at the same time?
(Log in to post comments)
Nested class devices and the future of the device model Posted Oct 20, 2005 16:31 UTC (Thu) by gregkh (subscriber, #8) [Link] Use a distro other than Debian :)
Seriously, other distros have this all sorted out just fine. Use Gentoo,
You have options, you don't have to live on the bleeding edge of
Nested class devices and the future of the device model Posted Oct 20, 2005 22:09 UTC (Thu) by hmh (subscriber, #3838) [Link] Other than Debian **UNSTABLE** you mean.
Nested class devices and the future of the device model Posted Oct 20, 2005 18:57 UTC (Thu) by iabervon (subscriber, #722) [Link] If there were an unstable branch, it would presumably break compatibility with 2.6, and it would be intended to become the future arrangement. And you would therefore definitely be wasting effort moving to 2.6, because the stuff you'd use wouldn't even be intended to work long-term. Having stable and unstable branches doesn't in any way resolve compatibility issues; it's just an excuse for breaking things.
I'd even venture to say that the fact that you're still using 2.4 and not 2.6 is that there's a lot of incompatibility due to the 2.5 series in between. Going from 2.6.0 to 2.6.13 breaks compatibility less than 2.4.27 to 2.6.0, even though there is more total change, because there isn't the expectation that there will be a major transition that changes everything.
Nested class devices and the future of the device model Posted Oct 20, 2005 20:08 UTC (Thu) by kleptog (subscriber, #1183) [Link] I'd even venture to say that the fact that you're still using 2.4 and not 2.6 is that there's a lot of incompatibility due to the 2.5 series in between. Going from 2.6.0 to 2.6.13 breaks compatibility less than 2.4.27 to 2.6.0, even though there is more total change, because there isn't the expectation that there will be a major transition that changes everything.Maybe, maybe not. Near as I can tell you need different versions of udev and hotplug depending on whether you're running 2.6.8, 2.6.13 or (soon) 2.6.16. No matter which way you turn it they're changing user-visible interfaces every other release in a backward incompatable way. It's a change though. During the 2.4 series I would regularly upgrade my kernel, fairly secure in the knowledge that after the reboot everything would just work. With 2.6 you upgrade and find that your module loading just broke, again. I'm glad there's a lot of guinea pigs out there willing to test the stuff, because I have a day job and work to do. Call me back we 2.8 releases and 2.6 stablises.
Nested class devices and the future of the device model Posted Oct 20, 2005 21:22 UTC (Thu) by iabervon (subscriber, #722) [Link] Switch to 2.6.13.x, and apply backported security patches. The new scheme essentially pushes the "everything stays the same" level down a digit, so 2.6.13 to 2.6.14 is essentially like 2.2 to 2.4, except that it won't break nearly as much. The main caveat is that I think it's worth waiting either for 2.6.x.1 or for 2.6.x to turn out stable, because the quality control on 2.6.x as first released isn't that good; 2.6.x is the point at which the version is turned over to the "stable" maintainers, not their first release.
I also haven't heard anything about module loading breaking, except for between 2.4 to 2.6. There has been code that's had bugs, and if it's built as a module, it causes problems when you load it, but that's hardly the same thing, and it isn't unlike problems that crop up on occasion in 2.4.
Nested class devices and the future of the device model Posted Oct 23, 2005 6:42 UTC (Sun) by thedevil (guest, #32913) [Link] Solution: ditch udev and hotplug, and compile a mostly monolithic kernelfor the hardware you have.
Just download one of the linux-source-2.6.x packages, untar
Nested class devices and the future of the device model Posted Oct 23, 2005 23:03 UTC (Sun) by zblaxell (subscriber, #26385) [Link] "they work with versions 2.6.8 to 2.6.12 but after that you need..."
...new versions of udev and hotplug to match, installed before rebooting.
Actually you don't *need* anything. I'm running 2.6.13.2 with udev 0.056 (Debian), and it works just fine in the default configuration. I have udev on hold at the moment as it seems that some or all later versions of udev are severely broken regardless of kernel version--after a few bad reboots I put everything on hold, and will revisit this problem the next time some other package forces me to upgrade udev.
AFAICT, with recent udev versions all of your old udev user-space configuration breaks, and you get new features that weren't in older udevs. It's possible that some really new devices or features in the kernel are therefore not supported at all by older udev, but that means new stuff won't ever work, not that old stuff that previously worked breaks. Of course if you had non-default configuration, it has most likely reverted to the default.
If you have a static /dev tree on your root filesystem, it will still work in 2.6.13 whether you use udev or not (assuming udev *itself* isn't broken, in which case it will be broken no matter what kernel you use). If you rely on a tmpfs-mounted /dev supplied by udev versions later than 0.056...I don't know what happens.
The biggest change IMHO between 2.6.12 and later kernels is that devfs went away. It's necessary to do some gymastics with 'mount --bind' to get the original root filesystem and make a '/dev/console' in it so that the subsequent reboot will succeed (assuming you've also installed udev)--my systems have had empty /dev on the root filesystem for some years now. This is such a huge, all-encompassing, all-breaking change, that it's pointless to discuss the various udev flavors.
|
|||||||||||