Greg KH <gregkh@suse.de> wrote:So e.g. lilo should depend on sysfs and *a*special*configuration* of udev, while the admin MUST NOT use mknod'ed device files nor manually create symlinks pointing to them, and not use relative path names? That's plain stupid. $ udevinfo /dev/hda missing option $ udevinfo /dev/hda --help Usage: udevinfo OPTIONS --query=<type> query database for the specified value: name name of device node symlink pointing to node path sysfs device path env the device related imported environment all all values --path=<devpath> sysfs device path used for query or chain --name=<name> node or symlink name used for query --root prepend to query result or print udev_root --attribute-walk print all SYSFS_attributes along the device chain --export-db export the content of the udev database --help print this text $ udevinfo --name=/dev/hda missing option $ udevinfo --name=/dev/hda --query=all P: /block/hda N: hda S: disk/by-id/ata-Maxtor_2F040L0_F1748ZQE S: disk/by-path/pci-0000:00:0f.0-ide-0:0 E: DEVTYPE=disk E: ID_TYPE=disk E: ID_MODEL=Maxtor_2F040L0 E: ID_SERIAL=F1748ZQE E: ID_REVISION=VAM51JJ0 E: ID_BUS=ata E: ID_PATH=pci-0000:00:0f.0-ide-0:0 As you can see, it gives no major:minor information. But it is in the DB: $ cd /dev/.udev/db $ grep -l hda * 2>/dev/null \x2fblock\x2fhda \x2fblock\x2fhda\x2fhda1 $ cat "\x2fblock\x2fhda" N:hda S:disk/by-id/ata-Maxtor_2F040L0_F1748ZQE S:disk/by-path/pci-0000:00:0f.0-ide-0:0 M:3:0 E:DEVTYPE=disk E:ID_TYPE=disk E:ID_MODEL=Maxtor_2F040L0 E:ID_SERIAL=F1748ZQE E:ID_REVISION=VAM51JJ0 E:ID_BUS=ata E:ID_PATH=pci-0000:00:0f.0-ide-0:0 What a great tool - for making linux look bad. --
| Linus Torvalds | Linux 2.6.27-rc8 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.20-rc6 |
| Mike Snitzer | Re: Distributed storage. |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Herbert Xu | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
