Bug 163410 – pcmciautils udev-rules could be cleand (was: sys-fs/udev-104-r1 uses half broken rule using modalias)

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description Matthias Schwarzott 2007-01-23 09:53:14 UTC]

sys-fs/udev-104-r1 contains in 50-udev.rules:

SYSFS{modalias}=="?*", ACTION=="add", RUN+="/sbin/modprobe $env{MODALIAS}"

This rule leads to udevtrigger calling /sbin/modprobe without argument almost 100 times for me.

Better alternatives could be:
1. ATTR{modalias}=="?*", ACTION=="add", RUN+="/sbin/modprobe $attr{modalias}"
2. ENV{MODALIAS}=="?*", ACTION=="add", RUN+="/sbin/modprobe $env{MODALIAS}"

[Comment 1 Matthias Schwarzott 2007-01-23 18:51:04 UTC]

pcmciautils also installs related rules:

Perhaps these should be checked against each other.

rules in 60-pcmcia.rules:

# modprobe $modalias loads all possibly appropriate modules
ACTION=="add", SUBSYSTEM=="pcmcia", ENV{MODALIAS}=="?*", \
                RUN+="/sbin/modprobe $env{MODALIAS}"

# Very few CIS firmware entries (which we use for matching)
# are so broken that we need to read out random bytes of it
# instead of the manufactor, card or product ID. Then the
# matching is done in userspace.
ACTION=="add", SUBSYSTEM=="pcmcia", ENV{MODALIAS}=="?*", \
                RUN+="/sbin/pcmcia-check-broken-cis"

# However, the "weak" matching by func_id is only allowed _after_ modprobe
# returns, so that "strong" matches have a higher priority.
ACTION=="add", SUBSYSTEM=="pcmcia", ENV{MODALIAS}=="?*", \
                RUN+="/bin/sh -c 'echo 1 > /sys/$devpath/allow_func_id_match'"

Perhaps 

[Comment 2 Matthias Schwarzott 2007-01-24 17:12:27 UTC]

Fixed in udev-104-r2.

It contains the version with ENV:
ENV{MODALIAS}=="?*", ACTION=="add", RUN+="/sbin/modprobe $env{MODALIAS}"


@mobile-herd:
It should be possible to remove that rule, as rule above does the same:
ACTION=="add", SUBSYSTEM=="pcmcia", ENV{MODALIAS}=="?*", \
                RUN+="/sbin/modprobe $env{MODALIAS}"

[Comment 3 Matthias Schwarzott 2007-01-25 21:18:14 UTC]

@mobile-herd:
Either remove that rule, or close the bug.
Known negative effect is only, that modprobe gets called twice for respective modules.

[Comment 4 Matthias Schwarzott 2007-02-08 20:03:25 UTC]

Closed, as only problem is one duplicated modprobe call.