lkml.org 
[lkml]   [2000]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you
    On Mon, Aug 21, 2000 at 08:51:57AM -0700, Linus Torvalds wrote:
    > On Mon, 21 Aug 2000, Philipp Rumpf wrote:
    > Right now, drivers/net is pretty horrible, for example, and we've started
    > separating things out a bit (ie drivers/net/tulip, drivers/net/pcmcia etc
    > to get a better hierarchy). Same thing happened to drivers/block -

    So we have drivers/net/pcmcia, but drivers/s390/net ?

    > > There seem to be at least four criteria for subdirectories of drivers/:
    > >
    > > drivers/<function> (sound, net)
    > > drivers/<interface> (char, block) (this isn't the same as function IMHO)
    > > drivers/<bus-the-device-is-on> (usb, sbus)
    > > drivers/<architecture> (s390, sgi)
    >
    > The last should probably be arch/<xxx>/drivers, but the other ones are
    > either sensible (tons of bus-independent drivers) or conceptual UNIX
    > things (char vs block).

    Do we have _any_ bus-independent drivers ? There are things like the serial
    driver which work with several busses, but they're not really independent in
    the sense that you could add a new bus type without any modifications to the
    drivers. I don't see a problem with putting those into drivers/common or
    similar, especially since the drivers I'm aware of still need bus-specific
    detection and initialization.

    So wouldn't it be the cleanest thing to do to split up the serial driver, put
    the generic parts into drivers/common/tty/serial.c, the PCI, ISAPnP, and GSC
    things (mostly detection) into drivers/{pci,isapnp,gsc}/serial/serial.c, and
    the architecture-dependent default ports into drivers/<arch>/serial/serial.c ?

    Basically what I'm proposing is to put drivers into
    drivers/<bus or arch>/<function or interface>/<name>.c
    it's obvious which APIs a driver uses (the <bus>-specific interface as well as
    the <function> abstraction), it helps keep #ifdef noise down (by splitting
    things up into separate files), and there is a relatively low number of places
    you have to look in for the driver you're searching.

    Another advantage is you'd be able to see all pci drivers as drivers/pci/*/*.c,
    and all network drivers as drivers/*/net/*.c (especially with the less popular
    subsystems / busses, where reading the existing drivers is a good way to find
    out API details).

    Philipp
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:37    [W:0.023 / U:89.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site