Messages in this thread | | | Date | Mon, 21 Aug 2000 08:51:57 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you |
| |
On Mon, 21 Aug 2000, Philipp Rumpf wrote: > > I have to admit I don't quite understand how drivers/ is organized right now.
There's a few "overlapping" organizations, which is why it certainly is confusing.
Basically, the thing originally was just "drivers/char" and "drivers/block". Nothing more.
It became quite unmanageable fairly quickly, because by the time you have a few hundred files in a directory, "ls" no longer gives the directory listing, it just gives tons of lines scolling by too fast to make much sense of it. And configuration etc is painful.
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 - although in that case the splitup happened to drivers/ide, drivers/cdrom.
drivers/char is messy, and _should_ probably contain only "fundamental char drivers" (ie things like basic tty layer stuff, ptys, /dev/zero, etc). It has too many "misc" drivers in it. Stuff like bttv, zr36120 etc. And the low-level serial stuff should probably go into drivers/serial or something.
> 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).
> I don't see any particular preference, and my impression is that new > directories get added pretty much at random.
I'm eager to add new directories if they help make for finer-granularity hierarchy.
The reason I dislike drivers/input is that it seems to collapse many drivers under one, and split up something that conceptually is clearly one tree (usb). So it fails both the "split things up for clarity" and the "organize things after something simple" idea.
Which is not to say that the drivers/ hierarchy is necessarily all that wonderful as-is.
Linus
- 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/
| |