Messages in this thread |  | | Date | Mon, 21 Aug 2000 23:30:35 +0200 | From | Vojtech Pavlik <> | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you |
| |
On Mon, Aug 21, 2000 at 11:45:12AM -0700, Linus Torvalds wrote:
> Indeed. > > Which is why I want all the USB drivers in one place. > > The USB interfaces are more likely to change than the keyboard interfaces. > When somebody changes how the USB urb's interact, I'd rather have all of > that under one tree. > > Think about it another way: what about a driver that implements a > touchscreen and a framebuffer device, all in one (imagine a graphics chip > with built-in touch-screen support)? Do you want to split it up, so that > the touchscreen part is in "input", and the framebuffer part is in video? > Imagine the nastyness when these "two" drivers have to synchronize over > shared resources? (This, btw, is how the PC keyboard + PS/2 mouse driver > worked. Nightmare with shared spinlocks etc). > > No. You don't split it up according to function. You split it up according > to other issues first, and _then_ you may sub-split it according to > function.
Ok, lets then move the input.c, mousedev.c, evdev.c, keybdev.c and joydev.c to a common directory (be it drivers/input, drivers/char, drivers/char/input or whatever then). Moving just input.c doesn't help anything.
I don't mind the drivers being sorted by the bus the interface (bus) they live on (gameport / usb / serial port / whatever) or by the interface they provide (scsi / input / network / whatever). Both have their logic. I believe the later is nicer, though.
Also, I doubt the usb interface is less stable than the input one, so I really believe both the choices are equal.
However, if now more than just the usb drivers use the mousedev, evdev, keybdev and joydev, and these (input -> chardevice) drivers don't live on usb or provide usb, they should be moved out of the usb dir to be accessible by others even when CONFIG_USB is not set.
input.c and the *dev.c files need to live in a separate directory or at least in a directory that is not dependent itself on any config option (drivers/char for example).
So: would you accept a patch that does this? I suppose yes. Should the destination be drivers/char? I suppose yes. Good. By the way, we are moving these files to a directory named by what they provide. (The opposite of the usb approach). Not that I mind ...
-- Vojtech Pavlik SuSE Labs - 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/
|  |