Hi Dan, Jeremy,
Thank you very much for your thoughtful and valuable comments.
Dan Nicholson wrote:
> I'm on 2.6.20 and there are still modalias files under
> /sys/bus/*/devices/*/modalias.
> That may have changed in 2.6.21, though.
Jeremy Henty answers:
> Apparently not:
> [I'm on 2.6.21.5-0]
> ls -1d -- /sys/bus/*/devices/*/modalias | wc -l
> 38
Alex is commenting on the above (verbosely):
I use 'find' to show me only the "real" files:
find /sys -name modalias | wc
27 27 1164
find /sys/devices -name modalias | wc
24 24 1065
find /sys/class -name modalias | wc
3 3 99
find /sys/bus -name modalias | wc
0 0 0
The 'ls' thing traverses symlinks as well and thus counts
certain "files" twice (or who knows how many times),
see the Example below.
The 'ls -1d -- /sys/bus/*/devices/*/modalias' which,
by the way, is equivalent (on my system) to
'ls /sys/bus/*/*/*/modalias'
and if we stay with 'ls' the most comprehensive
in our search for the truth would anyway be
'ls /sys/*/*/*/*/modalias', to show "all"
"/sys" modalias "files".
On my system 'wc' would show 44 "files", with
ls /sys/bus/*/*/*/modalias | wc
24
ls /sys/class/*/*/*/modalias | wc
17
ls /sys/devices/*/*/*/modalias | wc
3
Example -- I randomly picked this branch:
ls -l /sys/bus/platform/devices/floppy.0
lrwxrwxrwx 1 root root 0 2007-06-28 08:16
/sys/bus/platform/devices/floppy.0 ->
../../../devices/platform/floppy.0
Obviously, we're talking about the same file:
ls -l /sys/devices/platform/floppy.0/modalias
-r--r--r-- 1 root root 4096 2007-06-28 12:28
/sys/devices/platform/floppy.0/modalias
ls -l /sys/bus/platform/devices/floppy.0/modalias
-r--r--r-- 1 root root 4096 2007-06-28 12:28
/sys/bus/platform/devices/floppy.0/modalias
cat /sys/devices/platform/floppy.0/modalias
floppy
cat /sys/bus/platform/devices/floppy.0/modalias
floppy
As to the main topic #1,
"are the 'modalias' files in '/sym/bus' or not?"
in the final analysis the answer depends on who
you talk to and the mood of the particular point in time.
People who love symlinks will say yes, the ones who
go for "real" files (even if they exist for only a
fleeting moment in memory here) will say no :)
---
Topic #2
Alex wrote:
>> ...
>> Could my 'failed' be the elusive 'tmp-rules--*'?
>> I didn't spot any rules there.
Dan answers:
> No. tmp-rules--* are needed only occasionally ...
Alex:
Dan, excellent clarification. Thanks.
However I'd like to add my few cents on this
subject here, FWIW.
After boot, I invariably end up with some twelve
entries in '/dev/.udev/failed' directory.
To stay with the same tired example above,
for example, the "floppy" entry looks like so:
\x2fdevices\x2fplatform\x2ffloppy.0
If I use 'udevtrigger --verbose' in 'udev_retry'
I get its counterpart on the console during boot:
/devices/platform/floppy.0
(actually, not surprisingly, I see all 12 of'em, always).
The funny thing is 'failed' remains forever untouched
(with its 12 entries) and BTW, my floppy works OK)
Despite my making a lot of progress in getting a
grasp on Udevicing, it still seems like black art to me.
---
Topic #3
Alex wrote:
>> In 'udev' I noticed that appending '--timeout=3'
>> to 'udevsettle' speeds up the boot considerably
>> while not missing any devices in doing that.
Dan comments:
> I don't recall exactly how udevsettle works, but if you specify a
timeout, that's exactly the maximum time udevsettle will run for. The
default is 180. Otherwise, udevsettle checks /dev/.udev/uevent_seqnum
and /sys/kernel/uevent_seqnum 20 times per second. It runs until the
value in /dev matches the value in /sys.
So, if it's much faster for you, then I don't think you've waited
until all the pending uevents have been processed. If you're curious,
you can set UDEV_LOG=info for udevsettle. This would show if the
timeout is reached or the queue is empty in syslog. If you don't
process all the events immediately, then it's entirely unknown whether
to proceed, although probably OK at that point.
Alex:
Another excellent explanation. Thanks.
As I alluded to above, I never felt like I missed any
device (event?), whether with timeout or not.
Anyway, I'll do some research around the
" UDEV_LOG=info" business.
Interesting stuff.
Once again, many thanks,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
