[lkml]   [2000]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you

    On Mon, 21 Aug 2000, Philipp Rumpf wrote:

    > On Mon, Aug 21, 2000 at 12:02:03PM -0700, Linus Torvalds wrote:
    > >
    > > Yes, people always worry about common chips, but they don't happen all
    > > that often in the end, and the pain from trying to share the code is
    > > usually much MUCH bigger than the pain from just occasionally stealing
    > > code from the other guy.
    > So you think it's a good thing we have 5 serial drivers rather than one, and
    > it'd be a good thing to split up the one we have into several drivers again ?


    Which does not mean that we should just duplicate all the code. The same
    way we don't duplicate the whole TCP/IP stack for each network card
    driver. There are tons of common issues in serial cards, and it's probably
    a good idea to have common code. But you should not take it too far.

    I think the current serial.c is starting to be a major mistake. That one
    driver tries to handle everything from the original 16450 all the way up
    to serial multi-port cards that happen to just be multiple 16550's with
    some tweaks. As a result, the driver is quite complex and huge and is a
    mess of #ifdef CONFIG_xxx.

    A lot of serial.c is actually completely hardware-independent, and
    serial.c in many ways is already "two drivers", in that it both knows how
    to handle the low-level hardware AND it knows how to handle the
    higher-level issues. And I don't think it would be bad to split it up some

    I would not be unhappy to have separate drivers for different chipsets,
    and even if you want to have the same driver for a 16450 and a 16550 (they
    _are_ quite close, after all), it's not clear that it makes sense to do
    the same thing for the multiport things etc.

    > I think what might be saving us right now is that there is only one widely-used
    > bus architecture (PCI and it's derivatives/predecessors), so no-one is going to
    > implement conflicting new features in both parts of a split driver.

    And this is not going to change. Everything but PCI is dead, and there
    isn't going to be multiple different buses. Sure, we'll have some serial
    new-generation stuff, and we'll continue to have things like USB, but I'm
    not worried about having the same chip on different buses. It'
    s a thing of the past.

    > I don't think "there aren't going to be a great many file in this directory"
    > is really a good argument against creating a directory, except for the very
    > special case that there would be no files at all in it.

    I think you're wrong.

    Logical naming and hierarchy are only helpers. If they lead to people
    finding the files more quickly and understanding them better, they are
    doing their job.

    If hierarchy leads to having to look more places, think about it more, and
    just more work, that hierarchy is BAD. It doesn't matter if it is logical
    or not. It sucks. It just ends up being in your way.

    We could create a subdirectory for each driver. In some cases we _do_
    that (tulip and ide come to mind). But in the end, it should be done only
    when it clarifies things, not just because somebody thinks it "ought" to
    be that way.

    And "there aren't going to be many files in this directory" is an argument
    against it. It means that the directory doesn't end up clarifying things
    very much at all.


    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 12:37    [W:0.024 / U:2.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site