| |||||||||||||
MistakeMistakePosted Sep 30, 2004 3:38 UTC (Thu) by dvdeug (subscriber, #10998)In reply to: Mistake by elanthis Parent article: Driver core functions: GPL only
If they can't get a new kernel, where are they going to get modules compiled for thier current kernel? Why isn't making the most current kernel available for older distributions better a good solution to this problem?
(Log in to post comments)
Mistake Posted Sep 30, 2004 14:12 UTC (Thu) by elanthis (guest, #6227) [Link] Because each minor kernel revision includes massive changes. It's foolish to expect a distro to QA a new kernel when it has such huge differences in it besides just updated drivers. You'd either spend sickening amounts of developer time for each kernel release, or you'd destabilize your users's systems.
Getting new drivers is easy. The driver could be delivered on a CD with the hardware. Web sites (like the hardware vendors' or a central Linux Driver Database) could contain simple driver packages.
As things work now, to release a usable driver, you have to package the driver for each kernel revision of each os release of each architecture of each os. That's a hell of a lot of drivers.
You don't really *need* ABI stability. Even just API stability would work. Then you could use something like DKMS, or another similar system, to install drivers. A simple "driver package" could be delivered on CDs or on a vendor's web site that let normal users click-and-install drivers; the driver would just be compiled and installed, initrd images updated, etc. When a new kernel is installed, the driver would just be rebuilt. That's only possible with a stable API, though.
A stable ABI would help when you want to install an OS on newer hardware. A compiler is generally not going to be available on the installation image, and even running a compiler in that environment is iffy at best. A stable ABI would let vendors ship a single binary that users could load off of a disk during installation to get support for such things as disk controllers or network cards that they need access to in order to install the machine.
Again, this is all assuming only GPL modules. I'm fine with the kernel devs legally banning non-GPL modules. Just make it possible to actually *use* the GPL modules.
stability is a chimera Posted Oct 5, 2004 8:35 UTC (Tue) by mbp (subscriber, #2737) [Link] Person A would like the kernel to stop changing altogether, except for remotely-exploitable security fixes. Person B wants it to stop changing except for serious bugs and all security fixes. Person C wants all the above, plus support for yet another little USB dongle. Person D needs support for a major new class of device such as SATA, a clean implementation of which means reorganizing the block layer. Person E needs the kernel to run well on their new 64-way Itanium and so needs variable size pages and other trickery.
Who should win? Just how stable do you want the kernel to be? There is no way to please everyone? Any feature which you consider churn is absolutely critical for someone else.
It is a fundamental design assumption of Linux that the internals can change to meet changing circumstances. If new devices require changing the abstractions, they will change. Trying to keep an ABI stable favors ABC at the expense of D and E, and there's no reason to do so.
In the 2.6 model, the kernel.org tree is not going to try to please any of these people. They are going to develop the kernel as best they can.
If you need more stability than that, you need to do it yourself or get it from a distribution. Linus is doing nothing to prevent people making branches with whatever stability criteria they want. He's just not going to interrupt development to pursue the criteria that you personally want, because other people have different goals.
This is a key difference between Linux and commercial projects: they have a single timeline, a single project plan, a single set of stability goals, and can decide to go into a stablity phase. That doesn't make sense for a project with such diverse users as the kernel.
stability is a chimera Posted Oct 13, 2004 15:30 UTC (Wed) by jai0 (subscriber, #23440) [Link] Dude, that was just amazing. Now I've got a good reply to those who ask me about these zillion kernel versions, incompatible kernel modules, etc.. Thanks.
|
|||||||||||||