A new device naming scheme [LWN.net]

A recent posting on linux-kernel announced the creation of a new mailing list, hosted at OSDL, for the discussion of device naming schemes. The Linux Standard Base does not currently specify device names, but its maintainers would like to change that. To that end, they are seeking input on how devices should be named on Linux systems.

The discussion, so far, has centered around a proposal (available in PDF format) from SUSE. Its purpose is to create a set of persistent device names which will remain valid even in a hotpluggable world where the hardware configuration can change at any time. To that end, the proposal creates a version of /dev which is radically different from anything seen on current Linux systems.

All of the current device names found in /dev are relegated to the category of "compatibility names." They will still exist, but the proposal suggests that they should be maintained by udev, rather than being a static part of the system. The new names, instead, will all be found in subdirectories under /dev. Disks will be in /dev/disk (with a "k"), and the obvious things will be found in other directories, such as /dev/printer, /dev/cdrom (these, evidently, are not "disks"), or /dev/modem.

The proposal calls for another level of subdirectories before you find any actual device names. Each of the /dev subdirectories would be further divided into by-path, which names each device by how it is connected to the system; by-serial, which uses the device's model name and serial number; by-uuid, which uses a device's "universal unique identifier"; and by-label, which uses a device's filesystem label. Thus, a system's root partition might have all of the following names:

/dev/disk/by-path/ide-0.0-part1
/dev/disk/by-serial/ata-ST340810A-53-5BIN-part1
/dev/disk/by-label/label-ROOT
/dev/disk/by-uuid/uuid-0bee1954-b245-4df1-b2af-785fecd75b8f

The use of multiple names for the same device does not sit well with everybody; fears have been expressed that it could confuse users and applications which perform user-space locking by device name. The by-path names were received critically; since the path can change on a modern system, those names will never be persistent. There were also complaints about by-label and by-uuid; those names are meant to allow Linux systems to find and mount disks regardless of their position in the device hierarchy, but the mount utility already implements that functionality.

While there have been complaints about the SUSE proposal, there have not, thus far, been a lot of alternatives put forward. Something, however, is clearly going to have to change. A Fedora Core 2 Test 2 system has almost 19,000 entries under /dev; this mass of names can only get larger and increasingly unmaintainable. And it fails to address the dynamic nature of devices in modern systems. Device naming looks to be an interesting issue for some time to come.

(Log in to post comments)

A new device naming scheme

Posted Apr 8, 2004 9:20 UTC (Thu) by james (subscriber, #1325) [Link]

Um.

A udev (or devfs) system that creates device nodes on the fly is going to have far fewer entries in /dev. And this proposal calls for udev anyway.

So this proposal should be compared to just adopting udev, not the current situation: where will it increase complexity and where it will decrease it? And is it worth the tradeoff?

James

What's wrong with udev?

Posted Apr 9, 2004 11:59 UTC (Fri) by Duncan (guest, #6647) [Link]

It's not hard to propose a solution better than a static /dev, with the
mentioned device proliferation problems, neither is it incredibly
difficult to propose a solution better than 2.4's devfs, altho it already
solves the worst of the static /dev issues. However, as James already
asked, where's the comparison to udev and a list of problems (other than
standardized names, but that's a separate issue) udev doesn't solve that
this new SuSE proposal does?

Again as James already mentioned, the SuSE proposal already calls for udev
anyway, and with it running, the overpopulated /dev issue is already
pretty much dealt with. SuSE can use it to build such a complicated thing
on their distrib if desired, but I don't WANT all those extra names on MY
system. In addition, the additional classifications they want are already
accessible thru /sys, which udev uses as well, and it shouldn't take much
effort to run thru the /sys info itself to grab the desired info and sort
it as needed in userspace, with the udev libraries and tools already
providing good programmer access to the info. If they want it organized
differently, why not simply patch the existing library interface to
provide the desired sort access and leave it at that?

Udev is already incredibly flexible, providing most of this functionality
if desired and much more. Why reinvent the wheel here, when simply
tweaking the spokes or changing the hub's sleave bearings to ball bearings
is all that's needed?

Duncan

A new device naming scheme

Posted Apr 12, 2004 20:48 UTC (Mon) by Peter (guest, #1127) [Link]

This issue can't be a Linux only issue. What are other OSs doing?

AIX has a dynamic /dev created by userspace during boot. Similar to udev, conceptually. Hard disks get named hdisk0, hdisk1, etc. in the order they are detected; after initially being detected by the system, their UUID or something is stored in a registry (the ODM) so that they always get the same identifier thereafter. (This persistence of names is not even all that important for disks, since AIX almost always uses disks via its LVM, which has no need to care about device IDs since it uses its own superblocks.)

So, AIX remembers all the devices it has ever detected on your system - or been told about via /sbin/mkdev. Devices it has successfully initialised are put in the available state, which involves creating the device node in /dev; devices which were not detected are put in the defined state, where device nodes in /dev are not automatically created. Major numbers are assigned dynamically, I think even for core stuff like /dev/null. And if you want to purge old entries from its database for stuff you no longer have plugged in, you have to do this manually, with /sbin/rmdev -d.