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, Aug 21, 2000 at 07:48:15AM -0700, Linus Torvalds wrote:
> > NOTE (for Linus): beside the Changes to the makefiles and {C,c}onfig.ins
> > this is the same as moving drivers/joystick/*.c and drivers/usb/{evdev.c,
> > hid-debug.h, hid.c, hid.h, iforce.c, input.c, keybdev.c, mousedev.c, usbkbd.c,
> > usbmouse.c, wacom.c } to drivers/input
>
> I have yet to understand WHY all of this is done.

It's done to have all drivers that use the new input layer in one place.

>
> Why?
>
> I personally think this is a major step backwards. Moving things to be in
> the same directory just because it made some configuration easier.

The configuration problems were only a side-effect of having the input stuff
spread around in the tree.

> Nobody
> has explained to me why you couldn't just add one new configuration
> option, and make the affected drivers (in their regular places) dependent
> on that configuration option.

It could be done. But having related drivers in one place is the
cleaner solution (IMHO).

> Are all the SCSI drivers going to be under drivers/scsi/? No. The "normal"
> ones that don't have any better place for them are, but nobody has really
> suggested moving drivers/usb/storage around to another place just because
> it uses the SCSI layer.

Having the usb storage stuff in drivers/scsi seems not too ugly to me.

The general problem is (and it is already discussed in this thread) having
a proper scheme for drivers/. Currently there is no scheme.

IMHO there are three appronpinquate shemes:

1. Group drivers by the subsystem they belong to:
drivers/usb
drivers/scsi
drivers/ide

2. Group drivers by their interface and function. Examples:
drivers/input
drivers/sound
drivers/video

2. Group drivers by the bus they are on. Examples::
drivers/scsi (the real scsi drivers, not the scsi controller)
drivers/i2c (the i2c clients only)

and additionally:

driver/pci for pci drivers (not the pci subsystem!)
drivers/isa for isa drivers
drivers/ic for bus independend drivers
drivers/pseudo for pseudo devices

In my opinion 3.) is the best solution. But following at least one
of this alternatives strictly would make the tree a lot cleaner.

Christoph

--
Always remember that you are unique. Just like everyone else.
-
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 12:37    [W:0.097 / U:8.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site