Messages in this thread |  | | Date | Mon, 21 Aug 2000 19:49:53 +0100 | From | Philipp Rumpf <> | Subject | Re: [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/
|  |