Messages in this thread | | | Subject | Re: [Q]: Linux and real device drivers | From | Jes Sorensen <> | Date | 22 Sep 1999 23:20:44 +0200 |
| |
>>>>> "David" == David Hinds <dhinds@zen.stanford.edu> writes:
>> However I still think that drivers residing in the kernel tree is >> the right way to go, it is such a pain maintenance wise having to >> deal with modules coming from the outside - PCMCIA is a perfect >> example of this.
David> Whether it is a pain maintenance-wise depends very much on what David> you need to do. I think the vast majority of users would be David> much happier to be able to get new drivers and driver updates David> without having to upgrade their kernel to the latest and David> greatest (which is usually a development kernel, not a stable David> release, and which may require upgrading a variety of David> user-level tools). On the other hand, standalone driver David> distributions are inconvenient for people who want to follow David> the latest kernel developments.
Oh I didn't state anywhere that one should not keep drivers available on a public web page or similar for people to upgrade older kernels - thats basically what Donald Becker does and I do it as well.
David> It is easier to maintain unmaintained drivers when they are in David> the kernel tree. That is, if a driver doesn't have an active David> maintainer, the only way it will be kept up to date with David> respect to kernel API changes is if it is in the kernel tree David> and can be updated by the usual global find-and-replace style David> of update. For drivers that are under active development and David> have active maintainers, I know that people like me, Donald David> Becker, and probably others, find this style of "maintenance" David> very frustrating.
I don't know what Donald's point is on this one, but I do know that a maintainer is not always available or has time to upgrade something when a kernel is upgraded. I know of this, I do have drivers of my own, and even though I admit it can be nuisance, it is still the only way for people to get a chance to use the code.
David> Active driver development requires that an David> author maintain their own source tree independent of what is in David> the kernel (whether it can actually be built standalone or not David> is a separate issue).
Why are you trying to explain this to me like I never wrote a line of kernel code.
David> The current big-kernel-tarball approach David> encourages kernel API drift (since some developers are David> indifferent or oblivious to the impact of changes on things David> that are not in the kernel tree) and version skew between what David> is in the kernel tree and what is in our driver development David> trees.
API's have to change sometimes for various reasons, this is how the Linux kernel development model works. Fortunately Linus is not afraid of braking the API if some serious bug is found that cannot be fixed without breaking the old API.
David> The strategy of putting all device drivers in the kernel tree David> is fundamentally unscalable.
It is the only thing that work, real life has proven that.
David> No one is going to want to hand propagate kernel API David> changes through 1000 (or 5000) device drivers in the kernel David> tree just to get a clean build, or even to wade through that David> many kernel config options to find the ones they want.
Thats what tools like perl and sed were invented for.
Jes
PS: Please fix your mail client top stop eating the References: lines, it is very rude.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |