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/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:05 EST