lkml.org 
[lkml]   [1999]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Q]: Linux and real device drivers
From
Date
>>>>> "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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.044 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site