pnp rc

Hi,
this patch clean the /etc/hotplug/isapnp.rc.
It is based against debian hotplug version.

I saw that you add recently in your cvs a pnp.rc.

You will see that your version also try to load anolog for PNPB02F instead of the gameport driver ns558. And it is not right because anolog is a joystick driver not the generic gameport driver we want.

pnp.rc it is near 4 time longer than the debian version :

$ time /etc/hotplug/isapnp.rc start
     floppy: loaded sucessfully
     8250_pnp: loaded sucessfully
     8250_pnp: loaded sucessfully
     parport_pc: loaded sucessfully
     ns558: loaded sucessfully
     snd-mpu401-pnp: loaded sucessfully
     rtc: loaded sucessfully

real    0m0.254s
user    0m0.103s
sys     0m0.109s

time ./pnp.rc start
floppy: already loaded
8250_pnp: already loaded
8250_pnp: already loaded
parport_pc: already loaded
ns558: already loaded
analog: can't be loaded
missing kernel or user mode driver analog
snd-mpu401-pnp: already loaded
rtc: already loaded
pcspkr: loaded successfully
psmouse: loaded successfully
atkbd: loaded successfully

real    0m0.908s
user    0m0.430s
sys     0m0.376s

Also ./pnp.rc list even modules that are compile with the kernel : here pcspkr, psmouse, atkdb...

Matthieu

@@ -26,7 +26,6 @@
     fi
 
     cat /sys/bus/pnp/devices/*/id \
-    | sed -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
     | while read MODULE; do
 	# get the name of the module which should be loaded
 	MODULE=$(modprobe --show-depends -q pnp:d$MODULE | sed -e '$!d;s/.*\/\(.*\)\.ko .*/\1/')

@@ -1,12 +1,9 @@
 # These aliases are used by /etc/hotplug/isapnp.rc and are needed here
 # because the modules themselves are not providing them.
-alias pnp:dPNP0400 parport_pc
-alias pnp:dPNP0401 parport_pc
 alias pnp:dPNP0510 irtty-sir
 alias pnp:dPNP0511 irtty-sir
 alias pnp:dPNP0700 floppy
 alias pnp:dPNP0800 pcspkr
-alias pnp:dPNP0B00 rtc
+alias pnp:dPNP0b00 rtc
 alias pnp:dPNP0303 atkbd
-alias pnp:dPNP0F13 psmouse
-alias pnp:dPNPB02F analog
+alias pnp:dPNP0f13 psmouse

I give up. I think I'll just drop the pnp.rc or isapnp.rc file from the tree until someone steps up and offers to maintain it.

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

This bug applies to both versions of the script. In both pnp.distmap and isapnp.aliases, please remove the "analog" line completely (as opposed to what your patch does). The reason is that the "ns558" driver already contains this alias without our help, see

/lib/modules/uname -r/modules.alias

Thanks for the report. Don't forget to forward that to Debian bugtracker, since the bug is also there.

well - could you please improve the Debian version in order for it to be able to load e.g. the snd-es18xx module?

The strange thing is that you don't see this with isapnp.rc - this may happen if you forgot to add the contents of isapnp.aliases to your modprobe.conf file.

The recent Debian versions of isapnp.rc actually try to resolve these module names:

         MODULE=$(modprobe --show-depends -q pnp:d$MODULE | sed -e 
'$!d;s/.*\/\(.*\)\.ko .*/\1/')
         [ "$MODULE" ] || continue

So they do try to modprobe --show-depends e.g. the "atkbd" driver, but fail silently and continue (as opposed to pnp.rc when used with Debian's "functions" file -- that fails with some noise and continues).

As for Greg's statement concerning the maintainership: please give me a week to decide if I want to be a maintainer. The reasons for such a long delay is explained below.

1) I have to coordinate my actions with Marco d'Itri (from Debian). I remember his words about the idea with aliases being modern, progressive and right. The question is whether it is possible and good to apply this idea to pci.rc also. I think it is, but I want to know his opinion.

2) Currently with 2.6 kernels module-init-tools don't convert MODULE_DEVICE_TABLE(isapnp, ...) to modules.isapnpmap entries. They understand only pnp and pnp_card device maps. Because of this limitation, any isapnp hardware detection script that relies only on modules.isapnpmap (or, equivalently, aliases) is less useful that it might be. E.g. 3com network cards are not detectable. What is the correct list to discuss that limitation?

Alexander E. Patrakov


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

(in fact what I try to do here is to test this approach on a well-supported PCI bus and, in the case of success, drop pnp.rc in favour of isapnp.rc maintained at Debian).

Found a problem with this approach. If this idea with aliases is applied to the PCI case, let's see what happens to a user with an Intel EtherExpress 100 network card and some sort of a blg bloated modular "distribution" kernel.

There are two official drivers for this sort of card, e100 and eepro100.
In order to choose one, the user currently has to blacklist the other
by adding a line to /etc/hotplug/blacklist. Then the first non-blacklisted driver gets loaded.

With the approach based on the aliases (and blacklisting based on modprobe output, as currently done in Debian in isapnp.rc), it is difficult to implement. First, Debian-like solution:

	# Generate $ALIAS from the PCI ID
         MODULE=$(modprobe --show-depends -q $ALIAS | sed -e 

'$!d;s/.*\/\(.*\)\.ko .*/\1/')
[ "$MODULE" ] || continue
# and now check the module against the blacklist

This fails because modprobe will resolve only one of the candidate modules. E.g., suppose that it would (unwantedly) pick e100. I blacklist e100. $MODULE will still be e100, and as a result nothing will be loaded.

So we have either to ask Rusty Russel to add an option to modprobe to print all possible resolutions of an alias (BTW which list should this go to?), or implement that by grepping the output of "modprobe -c", like this:

# obtain $VENDOR and $DEVICE
MODULES=$(modprobe -c | grep "alias pci:v0000${VENDOR}d0000${DEVICE}" | 
grep -o '[^ ]*$')
# check against the blacklist

(yes, I know that I have to check subvendor and subdevice too).

Does this grepping sound like a good idea?

Alexander E. Patrakov


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Hi

and isapnp.aliases, please remove the "analog" line completely (as opposed to what your patch does). The reason is that the "ns558" driver already contains this alias without our help, see

bugtracker, since the bug is also there.

I send it a month ago, but no reply...

be able to load e.g. the snd-es18xx module?

Yes for isapnp, you need to pass to modproble the card and device id. For your card it is for example cESS1868dESS1868dESS0000. Unfortunatly I don't have any isa device, so I don't know if it is possible to recover all these id from sysfs. If not perhaps make a patch to export them via sysfs.

MODULE_DEVICE_TABLE(isapnp, ...) to modules.isapnpmap entries. They understand only pnp and pnp_card device maps. Because of this limitation, any isapnp hardware detection script that relies only on modules.isapnpmap (or, equivalently, aliases) is less useful that it might be. E.g. 3com network cards are not detectable. What is the correct list to discuss that limitation?

You could found it in modules.alias ?

Matthieu

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel