module-init-tools - input devices id support
this adds support for generating modules.inputmap with input handler match table that is used by input hotplug agent posted separately. Using hotplug allowed me to completely eliminate any manual (input handler) module loading in 2.6, it is also compatible with 2.4 in that usb.agent for 2.4 includes fake usb table that maps device class to input handlers so this is mostly transparent to users.
I do not have ability to test it on 64 bit system nor have any sufficient knowledge about ELF - please, check and adjust table size if neccessary.
the patch is against 0.9.13-pre and relative to previous temp file patch I sent. I can send patch against vanilla version if required.
Comments appreciated
-andrey
In message <[email protected]> you write:
Quoted 6 lines
this adds support for generating modules.inputmap with input handler match table that is used by input hotplug agent posted separately. Using hotplug allowed me to completely eliminate any manual (input handler) module loading in 2.6, it is also compatible with 2.4 in that usb.agent for 2.4 includes fake usb table that maps device class to input handlers so this is mostly transparent to users.
Hi Andrey,
For 2.6 you should not be using the maps generated by depmod.
You should be adding to scripts/file2alias.c, and using those aliases to insert modules. This is much more flexible.
Hope that helps,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 8 lines · Rusty Russell
In message <[email protected]> you write:
Quoted 6 lines
this adds support for generating modules.inputmap with input handler match table that is used by input hotplug agent posted separately. Using hotplug allowed me to completely eliminate any manual (input handler) module loading in 2.6, it is also compatible with 2.4 in that usb.agent for 2.4 includes fake usb table that maps device class to input handlers so this is mostly transparent to users.
Quoted 6 lines
Hi Andrey,
For 2.6 you should not be using the maps generated by depmod.
You should be adding toscripts/file2alias.c, and using those aliases to insert modules. This is much more flexible.
well ... file2alias assumes scalar fields with "is equal" or "do not care" values. Input handler matching requires bit (sub-)fields matching (with longest filed being 512 bits). I od not see how it can be implemented using standard alias syntax. This syntax fails even for some PCI entries already (while using pcimap allows for more elaborate matching)
Can you name some current users of module.alias?
thank you
-andrey
In message <[email protected]> you write:
Quoted 11 lines · Rusty Russell
Quoted 5 lines
Hi Andrey,
For 2.6 you should not be using the maps generated by depmod.
You should be adding toscripts/file2alias.c, and using those aliases to insert modules. This is much more flexible.well ... file2alias assumes scalar fields with "is equal" or "do not care" values. Input handler matching requires bit (sub-)fields matching (with longest filed being 512 bits). I od not see how it can be implemented using standard alias syntax.
Sorry for the slow response; am on holidays.
I'm confused. This is the first time I've looked at the input code, so please bear with me.
So, you hotplug in a device that has a suspend key, and you want the power.ko module to match it? Hmm, cool.
How about a mneumonic for each type? Like so fordrivers/input/power.c:
/* B: bus, V: Vendor, P: Product, R: Version. * E: evbit, K: keybit, A: absbit, M: mscbit, L: ledbit, * S: sndbit, F: ffbit. */ /* input:B*V*P*R*E*key*K*suspend*A*M*L*S*F* input:B*V*P*R*E*key*K*power*A*M*L*S*F* input:B*V*P*R*E*K*power*A*M*L*S*F*
You could use "p" instead of power, but the full names are probably better since they are clear and most drivers only seem to have a handful from my casual grepping.
Quoted 2 lines
This syntax fails even for some PCI entries already (while using pcimap allows for more elaborate matching)
Not in practice, at least so I was assured by Greg. Do you know of a counter example?
I really prefer generating aliases to hold this meta-information where possible, because it's so simple for anyone to use them.
Quoted 1 line
Can you name some current users of module.alias?
Well, noone uses it directly: it's an internal detail of modprobe. But it's designed for the hotplug stuff. I'll eventually get around to converting them if Greg doesn't first, because sooner or later those map files are going to break.
Hope that clarifies!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 13 lines · Rusty Russell
In message <[email protected]> you write:
Quoted 11 lines · Rusty Russell
Quoted 5 lines
Hi Andrey,
For 2.6 you should not be using the maps generated by depmod.
You should be adding toscripts/file2alias.c, and using those aliases to insert modules. This is much more flexible.well ... file2alias assumes scalar fields with "is equal" or "do not care" values. Input handler matching requires bit (sub-)fields matching (with longest filed being 512 bits). I od not see how it can be implemented using standard alias syntax.
Quoted 8 lines
Sorry for the slow response; am on holidays.
I'm confused. This is the first time I've looked at the input code, so please bear with me.
So, you hotplug in a device that has a suspend key, and you want the power.ko module to match it? Hmm, cool.
I have never thought about this particular example, but yes, input agent will do it even without me knowing it :)) and not only hotplug - you coldplug and boot and have all handlers ready.
Quoted 11 lines
How about a mneumonic for each type? Like so for
drivers/input/power.c:/* B: bus, V: Vendor, P: Product, R: Version. * E: evbit, K: keybit, A: absbit, M: mscbit, L: ledbit, * S: sndbit, F: ffbit. */ /* input:B*V*P*R*E*key*K*suspend*A*M*L*S*F* input:B*V*P*R*E*key*K*power*A*M*L*S*F* input:B*V*P*R*E*K*power*A*M*L*S*F*
Quoted 4 lines
You could use "p" instead of power, but the full names are probably better since they are clear and most drivers only seem to have a handful from my casual grepping.
The problem is not modules.alias (at least given curent input drivers). The problem is you have to convert driver data into this format to be able to match it. Now looking at my standard at keyboard:
pts/1}% cat /proc/bus/input/devices
I: Bus=0011 Vendor=0001 Product=0002 Version=ab02
N: Name="AT Set 2 keyboard"
P: Phys=isa0060/serio0/input0
H: Handlers=kbd event0
B: EV=120003
B: KEY=4 2000000 c061f9 fbc9d621 efdfffdf ffefffff ffffffff fffffffe
B: LED=7
I hope you do not seriously suggest something like
Knone-suspend-a-b-.... for all appr. 100 keys defined?
that is the main difference with PCI (and possible most others). They deal with single-value scalar fields. Input deals with bitfields where each bit counts.
Quoted 6 lines
Quoted 2 lines
This syntax fails even for some PCI entries already (while using pcimap allows for more elaborate matching)
Not in practice, at least so I was assured by Greg. Do you know of a counter example?
no. I base my supposition on file2alias code:
if ((baseclass_mask != 0 && baseclass_mask != 0xFF)
|| (subclass_mask != 0 && subclass_mask != 0xFF)
|| (interface_mask != 0 && interface_mask != 0xFF)) {
fprintf(stderr,
"*** Warning: Can't handle masks in %s:%04X\n",
filename, id->class_mask);
return 0;
}if it has special case I assume this special case is possible.
Quoted 10 lines
I really prefer generating aliases to hold this meta-information where possible, because it's so simple for anyone to use them.
Quoted 1 line
Can you name some current users of module.alias?
Well, noone uses it directly: it's an internal detail of modprobe. But it's designed for the hotplug stuff. I'll eventually get around to converting them if Greg doesn't first, because sooner or later those map files are going to break.
why should it break? And sorry, but I do not find modules.alias any more simple than current tables.
please understand - I am not against this syntax. I just fail to see how this particular task can be implemented using this syntax.
And input agent is really needed for 2.6 it immensly simplifies configuration task.
thank you for taking your time
-andrey
In message <[email protected]> you write:
Quoted 11 lines · Rusty Russell
Quoted 6 lines
I'm confused. This is the first time I've looked at the input code, so please bear with me.
So, you hotplug in a device that has a suspend key, and you want the power.ko module to match it? Hmm, cool.
I have never thought about this particular example, but yes, input agent will do it even without me knowing it :)) and not only hotplug - you coldplug and boot and have all handlers ready.
This is the only example I can think of: what else would you use the inputmap file for?
Quoted 11 lines
Quoted 7 lines
How about a mneumonic for each type? Like so for
drivers/input/power.c:/* B: bus, V: Vendor, P: Product, R: Version. * E: evbit, K: keybit, A: absbit, M: mscbit, L: ledbit, * S: sndbit, F: ffbit. */ /*I hope you do not seriously suggest something like
Knone-suspend-a-b-.... for all appr. 100 keys defined?
Not in the proc file, no: that would be silly. But there's no reason not to convert it to do the modprobe: sure, it'll be very long, but that's OK, at least it's clear. It has the advantage that if anyone else ever wants to use it, it's nice and simple to understand.
Quoted 3 lines
that is the main difference with PCI (and possible most others). They deal with single-value scalar fields. Input deals with bitfields where each bit counts.
Yes.
Quoted 17 lines
Quoted 5 lines
Quoted 2 lines
This syntax fails even for some PCI entries already (while using pcimap allows for more elaborate matching)
Not in practice, at least so I was assured by Greg. Do you know of a counter example?
no. I base my supposition on file2alias code:
if ((baseclass_mask != 0 && baseclass_mask != 0xFF) || (subclass_mask != 0 && subclass_mask != 0xFF) || (interface_mask != 0 && interface_mask != 0xFF)) { fprintf(stderr, "*** Warning: Can't handle masks in %s:%04X\n", filename, id->class_mask); return 0; }
Quoted 1 line
if it has special case I assume this special case is possible.
Yes, in practice noone does this because it doesn't really make sense:
when someone wants to match on finer granularity, we'll worry about it.
Quoted 5 lines
Quoted 5 lines
I really prefer generating aliases to hold this meta-information where possible, because it's so simple for anyone to use them.
Quoted 1 line
Can you name some current users of module.alias?
Quoted 8 lines
Quoted 5 lines
Well, noone uses it directly: it's an internal detail of modprobe. But it's designed for the hotplug stuff. I'll eventually get around to converting them if Greg doesn't first, because sooner or later those map files are going to break.
why should it break? And sorry, but I do not find modules.alias any more simple than current tables.
Because the aliases are added at kernel build time, which means that all the knowledge about the data structures is inside the kernel source tree, so they can change. And because the aliases are text wildcards, they're easy to extend cleanly, without requiring any tools to change. The PCI structure changed in a 2.4.0 test kernel, and broke the outside tools. Greg KH still flinches when you ask about it
8)
Quoted 2 lines
please understand - I am not against this syntax. I just fail to see how this particular task can be implemented using this syntax.
That's OK, we're having a refreshingly civilized discussion. If we can't find a way of doing this using the alias syntax, then we'll keep the map for input. But it'd be a shame for you to be the odd one out 8(
Quoted 2 lines
And input agent is really needed for 2.6 it immensly simplifies configuration task.
What is input agent? I have only glanced at the kernel code: could you explain to me how you would use the inputmap file?
Quoted 1 line
thank you for taking your time
No, thank *you*. It's always hard to come up with a new design when there are so many people doing different things in the kernel. But that's what makes it fun...
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.