2.3.51 tulip broken

[Bryan Stillwell]

On Thu, 16 Mar 2000, Jim Morris wrote:

> /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.

But doing one big update instead of incremental updates puts a damper on
how much other people can help out.  Personally I would prefer to have at
least a few people that are doing development on the driver than just one.
That way we can all benefit from each persons knowledge.  Maybe a cvs
repository of the tulip driver would be the answer?  Wouldn't it be better
if everyone worked on the driver in cvs and then /that/ driver was
included in the kernel?  I would /really/ like it if my card (LinkSys
LNE100TX) would work right out of the box without having to install
drivers from the second floppy or downloading Donald's latest version.  
It would make network installs a heck of a lot easier!  Then I wouldn't
have to install gcc to compile the driver.


> 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.

Isn't something like 95% of the kernel, drivers?


> 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.

I personally hate installing drivers off a floppy.  It's much easier if it
just works without having to change something on your system.


> 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! ;-)

In otherwords are you saying you would rather have someone different than
Linus be in charge of keeping track of device drivers?


> 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/

Donald does great work IMO, but I would really like it if somehow the
current kernel driver and his driver were joined again and be developed
jointly.  Maybe setting up cvs on Sourceforge would be the answer?


Have a nice day everyone!

Bryan Stillwell

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org