Key points there:
- "Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system."
- "udev executes entirely in user space" - means each user possibly sees different sets of devices, and explains why devices available later are different from devices available in early stages of boot up.
- "runs as a daemon on a Linux system and listens (via netlink socket) to uevents the kernel sends out if a new device is initialized or a device is removed from the system. The system provides a set of rules that match against exported values of the event and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to set-up and configure the device."
/etc/init.d/rcS also has following under prepare_start_udev():
echo -n "Mounting a tmpfs over /dev..."
mount -n -o size=$tmpfs_size,mode=0755,noatime -t tmpfs none /dev
... and if one checks for mounts in the N900, there should be an entry that says:
none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
... coupled with the user space architecture, probably explains why /dev looks quite different during preinit.
... in addition, 92-n770.rules has following rules (for creation of devices; corresponding to point 3 above):
KERNEL=="mmcblk*", IMPORT{program}="/lib/udev/mmc_id $env{PHYSDEVPATH}"
KERNEL=="mmcblk*p*", env{SLOT_NUM}!="", NAME="mmcblk$env{SLOT_NUM}p%n"
KERNEL=="mmcblk*", env{SLOT_NUM}!="", NAME="mmcblk$env{SLOT_NUM}"
... & yes, mmc_id seems to be the part that fixes IDs of the MMC...
which just gave me a still-not-so-solid-but-workable idea on how to reliably identify MMC devices during boot.
(ls -al /sys/block/mmcblk0 | grep device , trace its link to /sys/class/mmc_host/mmc1, and cat /sys/class/mmc_host/mmc1/slot_name.
I had no idea there was such a thing called udev & udevd & did a quick read on them.
http://en.wikipedia.org/wiki/Udev
Key points there:
- "Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system."
- "udev executes entirely in user space" - means each user possibly sees different sets of devices, and explains why devices available later are different from devices available in early stages of boot up.
- "runs as a daemon on a Linux system and listens (via netlink socket) to uevents the kernel sends out if a new device is initialized or a device is removed from the system. The system provides a set of rules that match against exported values of the event and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to set-up and configure the device."
/etc/init.d/rcS also has following under prepare_start_udev():
echo -n "Mounting a tmpfs over /dev..."
mount -n -o size=$tmpfs_size,mode=0755,noatime -t tmpfs none /dev
... and if one checks for mounts in the N900, there should be an entry that says:
none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
... coupled with the user space architecture, probably explains why /dev looks quite different during preinit.
... in addition, 92-n770.rules has following rules (for creation of devices; corresponding to point 3 above):
KERNEL=="mmcblk*", IMPORT{program}="/lib/udev/mmc_id $env{PHYSDEVPATH}"
KERNEL=="mmcblk*p*", env{SLOT_NUM}!="", NAME="mmcblk$env{SLOT_NUM}p%n"
KERNEL=="mmcblk*", env{SLOT_NUM}!="", NAME="mmcblk$env{SLOT_NUM}"
... & yes, mmc_id seems to be the part that fixes IDs of the MMC...
which just gave me a still-not-so-solid-but-workable idea on how to reliably identify MMC devices during boot.
(ls -al /sys/block/mmcblk0 | grep device , trace its link to /sys/class/mmc_host/mmc1, and cat /sys/class/mmc_host/mmc1/slot_name.
kh