lkml.org 
[lkml]   [1999]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PATCH 2.3.23 pre 2 compile fixes


    On Thu, 21 Oct 1999, Donald Becker wrote:
    >
    > The proposals to split up tulip.c into multiple drivers that supports
    > individual chips demonstrates a lack of understanding of the problem.

    Note that "split up" does not necessarily mean what you think it means.

    For example, it might be as simple as splitting up the detection and
    EEPROM code and the tranceiver code from the "real" tulip code.

    For example, all drivers would probably have the same actual code that
    accesses the ring buffer, because thats is all done by the actual tulip
    chip itself. So start_xmit, rx and tx would be completely shared. Those
    aren't the ones that have been particularly fragile.

    But the timeout handling and the media handling could probably be
    considered a separate driver altogether. Basically, the functions tend to
    be big case statements anyway, and maybe that should be be made more
    modular, so that it would be clearer what code is for the DC21041 and what
    is for the DC21142, because they have different routines to handle them.

    Note that I don't personally think the tulip driver is all that confusing,
    there are certainly much worse drivers out there. It just came up as an
    example by Richard as being prone to break in subtle ways, and splitting
    up the parts that break and making them more independent of each other is
    probably a good maintenance strategy.

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

    Note that nobody is suggesting that you dismantle the mailing lists.
    Instead, people are suggesting that you should _also_ make the thing more
    available, together with more history of what has been going on, and be
    aware that a driver on its own is useless - you as a driver writer would
    probably prefer it if the rest of the system stayed at 1.2.13 forever so
    that you wouldn't have to be part of a whole.

    But the fact is that no driver is an island. Even if you'd like them to
    be.

    Linus


    -
    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.029 / U:61.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site