Messages in this thread |  | | Date | Mon, 21 Aug 2000 19:51:17 +0200 | From | Christoph Hellwig <> | Subject | Re: [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/
|  |