Messages in this thread | | | From | Andreas Dilger <> | Subject | Re: My $0.02 on devd and devfs | Date | Mon, 11 Oct 1999 02:08:48 -0600 (MDT) |
| |
H. Peter Anvin writes: > The right solution -- which the devfs people have correctly identified > -- is a user-space daemon. However, once you have the user-space > daemon, "devd", I believe you neither need nor want the virtual > filesystem, in the general case. However, I can understand that in > some configurations (like embedded systems) it may be desirable.
[Despite my similar email address, I've never met Richard, nor used devfs, ] [although it is interesting to see people in Calgary working on Linux... ]
I've read a lot of the discussion about devfs pros and cons, and possible solutions. One of the recurring themes I've noticed is the desire for separation of automatic device detection from a virtual filesystem. Some of the supporters point to Irix and Solaris for examples of how it can be done, but I haven't seen any mention of the methods AIX uses for dynamic device configuration, so I thought I would mention it here as another data point for people to take into consideration (I work with AIX a lot).
* * *
AIX uses a real /dev filesystem as part of the root partition to store device inodes. This allows for the setting of permissions, ACLs, etc to be persistent across reboots, backed up, etc, and they are available at the earliest stages of boot. Device major and minor numbers are (for my understanding at least) assigned on demand for a class of devices with a 16/16 split (for example all SCSI disks are assigned a single major, but the major can change from one system to the next).
Devices are added to the system by running a command called "cfgmgr" (which is also run at boot), which starts a "recursive scan" of all devices on the system, and may add new device inodes into /dev. The initial device scan works by querying the system planar about what type and number of devices it has (e.g. PCI bus, ISA bus, keyboard+mouse ports, serial, etc) which are output to stdout, and then in turn a configuration script is run for each of these devices to see if they have child devices (e.g. PCI bus has an ethernet card, dual channel SCSI card, SSA disk adapter), which in turn spit out more child devices which get configured by their config scripts (if they are new to the system), etc. It is, of course, possible to run the configuration on only the PCI bus, or only for SCSI disks, if you know what was added, and don't want to run the whole configuration (which might take 20-30 seconds for a system with a hundred disks).
Disks, network adapters, serial ports, etc, all have nice symbolic names like hdisk0, en0, tty0, which are persistent across reboots because the internal details which map a device to a name are stored in an on-disk database, so we know hdisk0 is really PCI bus 0, slot 7, controller 0, target, lun, etc, and this information is mapped to a device minor. If cfgmgr is run on the system, and a new device is detected, it gets the next free name for devices in its class (e.g. hdisk205) permanently assigned, and a config script is run which will make the /dev inode, set default parameters for the device, etc. If a device already exists in the configuration database, nothing is done to the device or the database.
Devices can be either in the "available" state, or the "defined" state (which means that configuration information about the device is kept, even though the device is not currently available). To temporarily remove a device from the system, you run "rmdev -l <name>", which puts it in the defined state, and it is inaccessible (much like "ifconfig down <eth0>" should be). To get rid of a device permanently, you run "rmdev -d -l <name>", which will remove the config info from the database, and delete the inode.
Devices have default parameters set when they are initially configured, but these can be set in the database with "chdev -l <name> -a option=value" (e.g. "chdev -l ent0 -a full_duplex=yes" or "chdev -l scsi1 -a enable_wide=no"). Devices are listed via "lsdev -Cc <class>" (e.g. "lsdev -Cc disk" or "lsdev -Cc adapter" (there are optional sub-classes as well)). Device attributes can be listed via "lsattr -El <device>" (e.g. "lsdev -El eth0" tells me hardware information like interrupts, I/O addresses, alternate MAC address, duplex, etc - types of information specific to a class of device).
* * *
While the system isn't as dynamic as devfs sounds like (i.e. /dev entries aren't added and removed on the fly), it works very well for systems with hundreds of disks, serial ports, etc. The fact that it is a physical filesystem which keeps device permissions is important, as is the fact that the device inodes can be backed up via tar/dump/whatever. It is actually a good thing that devices missing from the system are kept across reboots (i.e. you need to manually remove them), so tape drive density settings aren't lost, and the fact that you had a disk called hdisk74 which is "defined" but not "available" helps when you are trying to figure out why your database won't start...
If there was anything that could be improved with this is if a parent device has a method of notifying the kernel that a new child has arrived, it could automatically run the configuration method for it (e.g. USB, or SSA disk loops which have their own daemons monitoring the topology). I suppose that you could also "clean up" the unavailable devices after a certain time (like cleaning /tmp), but this should be a user-space thing run via cron or whatever, based on the time the device became unavailable, and definitely not something automatic.
Hopefully someone finds this brief tutorial helpful in some way. The details are not fully covered here (like the fact that EVERYTHING is configured via the database, and the fact that AIX LVM doesn't really CARE what the disk devices are called), but it does cover what's pertinent to this discussion, which is /dev inodes and device addition/removal. I know some people hate AIX as the devil child of Unix, but from an administrative point of view, I like it. I'm not advocating this on anyone else, it's just information.
Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |