/ANOTHER SOAPBOX ON/
I have been following and using Donald's tulip.c for MANY YEARS...
Jim Morris wrote:
>
> Jeff Garzik wrote:
> >
> > No one expects anything from you and has not for a long time. If you
> > wanted to actually WORK on the drivers, rather than just complain,
> > then I'm sure many people including myself would find that work
> > very valuable.
>
> Whoa. I think you should simmer down quite a bit right now.
I totally agree with Jim Morris. Let's stop the wasteful
complaining!!!! I'll bet most of us are tired hearing it!
> /SOAPBOX ON/
> If you've followed the tulip driver development at all, you would know
> the reasons that the kernel drivers and some of Donald's ethernet
> drivers have "diverged". I have to side with Donald on a lot of the
> reasons too. Basically, if he is writing a driver, and want to maintain
> using a specific structure, that should be his perogative. And I feel
> that he ought to be able to send something like a complete copy of
> tulip.c, rather than small incremental patches, if he wants too. In
> this case, it is Linus who insists on small, incremental patch
> submission - and that isn't how Donald is setup to work.
Donald has worked hard to maintain a driver for "tulip", while, in fact,
there is NO "tulip" standard. Manufacturers have changed the guts of
the original "tulip" design in a willy-nilly fashion - without warning
(no new board/card designation changes). Donald has "busted his rump"
to keep up with all the changes - and simultaneously improve performance
of the driver.
Have there been problems, you bet. But Donald has responded over the
years as best as one could expect. Could he use a hand? Of course.
How about working together instead of this ridiculous, undermining
criticism!
>
> Think of it this way: it comes down to semantics. Are drivers like
> tulip.c standalone development projects, or kernel development? I know
> you will probably say kernel. But in reality, with the use of modules,
> that is not necessarily true. The driver runs as a kernel task - but
> doesn't really have to be part of the kernel source tree, when you get
> down to it.
>
> In most operating systems, including Linux, it is common for hardware
> vendors to supply a set of drivers on disk. You then load this driver
> on the running system to get your hardware to work. Think of the
> drivers on CESDIS along those lines, and maybe you'll get the picture.
> I.e. a device driver can be considered a separate peice of software that
> you load on the system, and not an integral part of the kernel.
> Including them with the kernel source is a convenience for the end user.
>
> When you get down to it, the Linux source tree is so darned big these
> days because of all the esoteric device driver support. In some ways it
> would be nice if there were two trees: a kernel tree, and a device
> driver tree! ;-)
Hear, hear!!!!!
> > I never claimed to be perfect but at least I am trying to fix some
> > of the the bit-rotten, UNMAINTAINED net driver code currently in
> > the kernel.
>
> Again - those drivers in the kernel had been modified and patched by
> various people over the years, via patches sent in to Linus. However,
> those patches were never sent in to Donald - the maintainer of the
> original driver. What do you expect him to do? I.e. he's chugging a
> long on developing a handy-dandy new version of tulip.c or whatever, and
> the one in the released kernel diverges from it because of patches he
> doesn't know about.... is he supposed to reverse engineer his own
> device driver, to get up to date?
>
> /SOAPBOX OFF/
/ANOTHER SOAPBOX OFF/
-- Lyle Bickley | Bickley Consulting West Inc. lbickley@best.com | V 650-428-0621 lbickley@acm.org | F 650-428-0599 "Black holes exist where GOD is dividing by zero"- 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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:19 EST