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, 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.377 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site