| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495 | Purpose of rules file:This rules file provides nonvolatile, unique names (in the form of symlinks)for various types of storage devices -- both IDE/ATA and SCSI.Description of rules:First, similar to the 60-persistent-input.rules file, we skip the entire filefor uevents that this rules file should not apply to, as an optimization.  Thefile does not apply to removal uevents or non-block devices.  It does not applyto ramdisks, loopback-mount devices, floppy disks, netblock devices, or device-mapper devices.  It also should not apply to removable devices (that is, non-partition devices with attributes named "removable" with the value "1", orpartition devices whose parents have "removable" set to "1" -- partitionkobjects don't have the "removable" attribute, only whole-disk kobjects do).For partition devices, we use the IMPORT{parent} option to pull in all theenvironment variables that get set for the parent device.  (The parent of apartition device is the containing whole-disk device.)  The IMPORT{parent}option is documented in the udev(7) manpage, but basically the value that weassign is used as a filter of environment variable names to import.Now, we start with rules to create by-ID symlinks (similar to the by-ID linkscreated for input devices).  For hd* whole-disk devices (they're IDE/ATA, since they start with hd), we run the ata_id program in --export mode.  The ata_idprogram requires a device node to be passed, so we also use the $tempnode Udevvariable -- this causes Udev to create a temporary device node somewhere andsubstitute its name where $tempnode appears in the program command line.The ata_id program, in --export mode, prints several ID_* values.  If we'relooking at a whole-disk device, and if ID_SERIAL is among those, we add asymlink containing the device's ID_MODEL and ID_SERIAL values.  If we'relooking at a partition device, we create an ID_MODEL- and ID_SERIAL-basedsymlink also, but we add -partX to the end of the link name (where X is thepartition number).For SCSI devices, we first make some modifications to the environment.  If thedevice's kobject has a parent with a non-empty "ieee1394_id" attribute, thenthe device is Firewire, so we set the ID_SERIAL environment variable to thevalue of that attribute, and we set ID_BUS to "ieee1394".  Now, if ID_SERIAL isnot set, we run usb_id, which (if this is a USB storage device) will printvarious values.  If ID_SERIAL is still unset, we run scsi_id with a set ofparameters designed to get an ID_SERIAL by querying the device itself.  If thatstill fails, we try running scsi_id in a mode that prints the information evenif the disk doesn't support so-called "vital product data" pages.  If theuevent is for a DASD device, we run dasd_id.If one of these *_id programs gave us an ID_SERIAL, then for whole-disk deviceswe create a by-ID symlink using the ID_BUS and ID_SERIAL.  For partitiondevices, we create a by-ID symlink that has the same form except we add -partXto the end (just like for IDE/ATA devices).Now we have some rules to create by-path persistent symlinks.  We start byrunning the path_id program on the DEVPATH (%p) value.  For whole-disk devicesand SCSI ROM type devices, we create a symlink directly, using the environmentvariable ID_PATH, under the /dev/disk/by-path directory.  But for SCSI tapedevices, we create a by-path symlink in the /dev/tape/by-path directory (webase the symlink on the same information, though: the ID_PATH value printed bypath_id).  Now, for both SCSI ROM and SCSI tape devices, we skip everythingthat's left in the rules file (this is another optimization: neither SCSI ROMnor SCSI tape devices have UUIDs, labels, or EDD information).For partition devices, we now create a by-path symlink of the same form as theother partition device persistent symlinks (that is, with the same name as theparent device, but with -partX added).  We know that ID_PATH is set whenever itapplies, because we ran the path_id program on the parent device, and we did anIMPORT{parent} on ID_* earlier in the rules file.Now we create by-label and by-uuid symlinks.  These use properties of variousfilesystems to generate a persistent name for a partition.  For instance, ifyou use the ext2 filesystem, you can use e2label to assign a label, and mke2fsassigns a UUID when the filesystem is created.  MS-DOS compatible filesystemsalso assign a "UUID" (actually it's just a serial number, created based on thedate and time the partition was formatted, so it is not unique), which theserules will also use.  But for removable partitions, we skip the rules (for thesame reason as we skipped them above for removable disks).We run the vol_id program to get ID_FS_USAGE, ID_FS_UUID, and ID_FS_LABEL_SAFEvalues.  (vol_id supports other values as well, but we do not use them here.)ID_FS_USAGE corresponds to the way the filesystem is supposed to be used; if itgets set to "filesystem", "other", or "crypto", we create a symlink.  IfID_FS_UUID is set, we use it in a by-uuid symlink.  If ID_FS_LABEL_SAFE is set,we use it in a by-label symlink.Finally, we create EDD-based symlinks in the by-id directory.  For whole-diskdevices, we run edd_id to get the EDD-generated ID string.  (For partitiondevices, we import this string from the parent.)  If edd_id yields an ID_EDDvalue, we use it in a symlink, for both whole disks and partitions.The last rule in the file is merely a LABEL that various other rules use tobypass the file (or the rest of the file) when needed.
 |