Re: [PATCH] input hotplug support

[Andrey Borzenkov]

On Tuesday 14 October 2003 03:56, Greg KH wrote:
> On Sat, Aug 02, 2003 at 12:53:02PM +0400, Andrey Borzenkov wrote:
> > On Saturday 02 August 2003 03:57, Greg KH wrote:
> > > On Sat, Aug 02, 2003 at 01:39:37AM +0400, Andrey Borzenkov wrote:
> > > > this adds input agent and coldplug rc script. It relies on patch for
> > > > module-init-tools that gnerates input handlers map table being posted
> > > > to lkml as well.
> > > >
> > > > input agent loads input handler in respond to input subsystem
> > > > request. It is currently purely table-driven, no attempt to provide
> > > > for any static list or like was done, it needs some operational
> > > > experience.
> > > >
> > > > static coldplug rc script is intended to load input handlers for any
> > > > built-in input drivers, like e.g. psmouse (if you built it in).
> > > > Currently it does it by parsing /proc/bus/input/devices, I'd like to
> > > > use sysfs but apparently support for it in input susbsystem is
> > > > incomplete at best.
> > > >
> > > > It also modifies usb.agent to not consult usb.handmap on 2.6, as it
> > > > is not needed anymore.
> > > >
> > > > Patch is against 2003_05_01 version of hotplug. Comments appreciated.
> > >
> > > Can you send it not compressed so we have a chance to read it?
> >
> > sorry.
> >
> > plain text attached.
>
> Thanks, I've applied this patch.  Did your module-init-tools patch make
> it into that package too?
>

No, Rusty was against it. You should have received those mails as well (you 
were on Cc at least), subject was

"module-init-tools - input devices id support"

If you do not have them I can forward or they are on lkml as well, sorry do 
not have pointers handy.

in short Rusty said the right thing is to use scripts/file2alias to generate 
module aliases out of input device id tables. While I do not object in 
principle, the reasons I did it the current way were

- it is consistent with how things are implemented currently and no one so far 
told me it is going to change

- I think it is more flexible. E.g. it provides for extra filtering 
(blacklisting) if needed. Doing this requires most of the current code (in 
some form) even in presence of aliases generated by file2alias

- given size of input id tables it will generate aliases of size more than 1k 
characters. Not that I really care but it is hardly readable.

- file2alias works only at kernel compile time. Users are free to install 
extra (binary) modules at any time and expect them to still be recognized.

I really think that keeping module-init-tools in sync with kernel is not much 
more difficult than keeping file2alias in sync with kernel. Whoever neglects 
update the former may just as well neglect to update the latter. And so far 
this was the main argument of Rusty IIRC.

cheers
	and sorry for delay too

-andrey

-
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/