[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, 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).

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.161 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site