2.3.51 tulip broken

[Lyle Bickley]

/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 send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org