Re: [PATCH 0/2] Remove input_call_hotplug

From: Dmitry Torokhov
Date: Tue Jan 18 2005 - 17:23:48 EST


On Tue, 18 Jan 2005 13:58:20 -0800, Greg KH <greg@xxxxxxxxx> wrote:
> On Tue, Jan 18, 2005 at 04:49:34PM -0500, Dmitry Torokhov wrote:
> > On Tue, 18 Jan 2005 13:30:02 -0800, Greg KH <greg@xxxxxxxxx> wrote:
> > > On Tue, Jan 18, 2005 at 03:56:35PM +0100, Hannes Reinecke wrote:
> > > > Hi all,
> > > >
> > > > the input subsystem is using call_usermodehelper directly, which breaks
> > > > all sorts of assertions especially when using udev.
> > > > And it's definitely going to fail once someone is trying to use netlink
> > > > messages for hotplug event delivery.
> > > >
> > > > To remedy this I've implemented a new sysfs class 'input_device' which
> > > > is a representation of 'struct input_dev'. So each device listed in
> > > > '/proc/bus/input/devices' gets a class device associated with it.
> > > > And we'll get proper hotplug events for each input_device which can be
> > > > handled by udev accordingly.
> > >
> > > Hm, why another input class? We already have /sys/class/input, which we
> > > get hotplug events for. We also have the individual input device
> > > hotplug events, which is what I think we really want here, right?
> >
> > These are a bit different classes. One is a generic input device class
> > device. Then you have several class device interfaces (evdev,
> > mousedev, joydev, tsdev, keyboard) that together with generic input
> > device produce concrete input devices (mouse, js, ts) that you have
> > implemented with class_simple.
>
> Hm, but we still need to make the input_dev a "real" struct device,
> right? And if you do that, then you just hooked up your hotplug event
> properly, with no userspace breakage.

I wasn't planning on doing that. The real devices are serio ports,
gameport ports and USB devices.They require power and resource
management and so forth. input_device is just a product of binding a
port to appropriate driver and seems to me like an ideal class_device
candidate. Then you add couple of class interfaces and get another
class_device layer as a result.

> Then, if you want to still make the evdev, mousedev, and so on as
> class_device interfaces, that's fine, but the main point of this patch
> was to allow the call_usermodehelper call to be removed, so that the
> input subsytem will work properly with the kernel event and hotplug
> systems.
>

I was mostly talking about the need of 2 separate classes and this
patch lays groundwork for it althou lifetime rules in input system
need to be cleaned up before we can go all the way.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/