[lkml]   [2000]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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
Please read the FAQ at

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