[lkml]   [1999]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH 2.3.23 pre 2 compile fixes
    On Thu, 21 Oct 1999, Richard Dynes wrote:
    > Jeff Garzik wrote:
    > >
    > > On a related note, what are the functional differences between tulip.c
    > > and de4x5.c?
    > I don't know is the short answer. I looked at the driver several
    > months ago, and it appeared to not be actively supported. A glance at
    > the code indicates that Nway is missing, but that's just a glance.

    There are many issues. The most obvious is that it recognizes all of the
    Digital chips, but works with relatively few boards. So you have a driver
    that claims boards that it doesn't work with (and it doesn't know it won't

    The proposals to split up tulip.c into multiple drivers that supports
    individual chips demonstrates a lack of understanding of the problem.

    I understand driver splits -- the 8390 code was split way back in '92. In
    that case there were multiple boards with lots of very different circuitry
    around a 8390 chip. OTOH the tulip driver supports lots of chips that all
    tried to be mostly work-alikes, with "minor" changes in some aspect. It's
    most like the NE2000 clone support -- those work-alikes are all slightly
    different/broken, but each in their own way.

    The most complicated parts are those driven by changes in the real Digital
    chips and design recommendations, not by the clone chips. The biggest,
    ugliest chunk of code is parsing the media selection in the EEPROM, which was
    revised endlessly by Digital and is shared by most chip types, but not used
    by all boards.

    A split would end up like the BSD drivers that have been added in the past
    few months -- a half dozen mostly-identical drivers. That will bloat the
    kernel code even more. Following this path will mean that we end up with
    about a hundred more drivers like drivers/net/am79c961a.[ch], which supports
    only a single chip type, pointlessly duplicating the support already in
    lance.c. The current problem is that Linus will always accept bloat like
    that. There is no way to say "it is not there because it should not be

    Keep in mind that the issue isn't just about tulip.c, or even the dozen
    other PCI network drivers I updated to remove the backwards compatibility at
    the request of Linus. It's about the process. I've been developing drivers
    this way, with supporting web pages, mailing lists and levels of test
    releases, for many years. I see people claiming that the process isn't
    transparent when they aren't on the mailing lists and obviously haven't
    looked at how much work and discussion have passed.

    Donald Becker
    Scyld Computing Corporation, and

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.036 / U:0.228 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site