| |||||||||||||
|
| |||||||||||||
Quote of the weekQuote of the weekPosted Dec 16, 2004 15:04 UTC (Thu) by elanthis (subscriber, #6227)In reply to: Quote of the week by mrshiny Parent article: Quote of the week
This isn't about binary modules!
It's about _all_ modules. Even GPL modules that are in-tree. If 2.6.10 has new module FooWhiz for some new harder, the only way for any user to use that hardware is to upgrade to 2.6.10. Distros are not going to release upgraded kernels, *especially* with the new kenerl development "model" (if you can call it a model), because new point releases aren't just bug fixes and driver additions, they're practically all new kernels.
So the only way for a user to get a new, upgrade perfectly GPL module is to upgrade their entire kernel. Manually.
(Log in to post comments)
Quote of the week Posted Dec 16, 2004 16:18 UTC (Thu) by ewan (subscriber, #5533) [Link] Rubbish. The way to do this is to install a distribution suppliedkernel update that has the GPL driver patched into it. Automatically.
Quote of the week Posted Dec 16, 2004 16:30 UTC (Thu) by elanthis (subscriber, #6227) [Link] No, sorry, not happening. Distributions do not just release newer kernels with new hardware support. Especially with the new kernel development model. How can they? Do you know how many months a kernel goes through stability testing before a distribution (a serious one, not a toy one) releases that kernel? Vendors aren't just going to grab a new kernel with tons of new drivers, driver changes, massive internal changes, and make a release.
You only get updated kernels with new drivers and new features when you upgrade your entire OS. If you are using a toy distro like Fedora, that might not be so bad, although having to potentially wait 6 months for a piece of hardware to start working is insane when, with a stable API, it could work _now_. If you are using a stable distro, you might have to wait a year or more.
Quote of the week Posted Dec 17, 2004 1:58 UTC (Fri) by mbp (guest, #2737) [Link] You seem to think that merely backporting some drivers would be a much easier task than upgrading the whole kernel, but I don't think that's necessarily true. The driver tree is more than half the weight of the kernel on any given architecture, and I think accounts for much more than half the churn from one release to the next. Fully qualifying a large machine can take a month of stress tests, and obviously this heavily exercises the drivers.
People want to stay on a single kernel version because they don't want things to break. Upgrading device drivers is a good way to make things break.
Quote of the week Posted Dec 17, 2004 12:58 UTC (Fri) by mrshiny (subscriber, #4266) [Link] Upgrading all the device drivers would be a good way to break something,but on a given machine, the size of the kernel plus the size of all the RUNNING device drivers probably throws the weight of the code back to the kernel's side. And often it's a question of needing a single driver, especially if it's for a new piece of hardware on an otherwise unchanged computer.
Quote of the week Posted Dec 17, 2004 19:51 UTC (Fri) by giraffedata (subscriber, #1954) [Link] The device drivers are part of the kernel (whether or not they're part of a Linux package distributed on kernel.org, and whether they are bound into the base kernel or loaded at run time). The question is merely is it better to upgrade one kernel module (a particular device driver) or upgrade the entire kernel. While there's a possibility that upgrading a part causes a problem that upgrading the whole would not, I think it's pretty obvious here that upgrading just one device driver module is safer than adding a year's worth of development spread out over an entire kernel to your system. In fact, if upgrading one module didn't work because someone made an incompatible interface change, I would sooner patch the interface than bring in a whole new kernel.
|
|
||||||||||||