meltin.net

Your computer runs Linux. It has 1 CPU, 256MB of RAM, 2 Ethernet interfaces, 2 IDE disks, a CD-ROM drive and a CD-RW drive. You reboot this machine every week or two to try out the latest kernel or to mess with a new revision of the X server. You know you've got /dev/hda1 and /dev/hda2, eth0 and eth1, so the configuration is pretty simple. When something goes wrong with one of the components, it is pretty easy to notice that you have a problem (using, say, logcheck) and to remove the cover and point to the faulty component (using your index finger).

My computer runs Linux. It has 32 CPUs, 64GB of RAM, 16 Ethernet interfaces, 540 SCSI disks, a CD-ROM drive and a CD-RW drive. The contract I have with my customer means that I'm allowed about 8 hours of unscheduled down-time per year. Luckily, everything is hot swappable. I need support for persistent device names or things are going to get ugly. I need to anticipate hardware problems, so I need some fancy software that wades through the messages that I get from all of this hardware. When I've detected that something is wrong with one of the components I'm going to need some diagnostic tools that let me figure out the exact physical location of the faulty component.

This paper looks at persistent device naming and hardware inventory requirements for Linux. There are quite a few solutions for persistent device naming but most, if not all, have disadvantages. There are several distinct stages in the hardware inventory process: you need to consider how you're going to obtain, store and use the information about the hardware. Should persistent naming use hardware inventory data or vice-versa? The discussion involves sysfs, Open Firmware device-trees, various user-space methods for retrieving hardware inventory data, some serviceability infrastructure that helps to make AIX a serious operating system... and much more.