That depends on the driver. input_dev is in general a static entry in the driver-dependend structure, which in turn may be statically or dynamically allocated (depending on whether the driver allows for more than one instance of the device to be connected).On Wed, Jan 19, 2005 at 02:48:14PM +0100, Hannes Reinecke wrote:
Hi Dmitry,
attached is the reworked patch for removing the call to call_usermodehelper from input.c
I've used the 'phys' attribute to generate the device names, this way we don't need to touch all drivers and the patch itself is nice and small.
The main problem of this is the input_dev structures are created statically, right? Because of this, the release function really doesn't work out correctly I think....
Would dynamic allocation be of any help here?
I must admit that reference counting in sysfs is still a somewhat darkish grey box to me.
Other than that this looks a lot better.
kewl.
Of course. I didn't see another way, as already stated the originial input events were something of a misnomer.Hm, you're still generating hotplug events with this patch of the "input_device" type, right?
So either I had to change the existing sysfs layout by renaming the current 'input' class and retain compability with the events
or change the event types and retain compability with the sysfs layout.
I opted for the latter, as AFAIK more userland tools might be reading from sysfs than processing hotplug events.
Cheers,
Hannes -- Dr. Hannes Reinecke [EMAIL PROTECTED] SuSE Linux AG S390 & zSeries Maxfeldstra�e 5 +49 911 74053 688 90409 N�rnberg http://www.suse.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
