[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:
> 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

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

> 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

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.


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 13:58    [W:0.218 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site