What's in a (device) name?

[Mike Meyer]

In <9399827.1657341144611794358.JavaMail.root at vms070.mailsrvcs.net>, Sergey Babkin <babkin at verizon.net> typed:
> I think this is a problem consisting of multiple parts:
> 
> 1. Identify physical devices and be able to access them.
> 
> 2. Identify some stable "logical" names by device type,
> that stay fixed when the configuration changes.
> 
> 3. Be able to find the mapping easily between these two.
> 
> 4. Be able to change that mapping.

I think you're looking at only two of the three aspects of the naming
problem. This covers dealing with systems administration, but not
using the system. Solving that for a particular device type might make
the "logical" name unneeded. Then again, it might not.

> So, since we have devfs nowadays, why don't we just
> have multiple names (dev files) for the same device? 
> For example, the same device can be named by driver 
> aha0b0t0d0 and by logical type disk0. The 3rd part
> can be solved by using symlinks in devfs: i.e.
> disk0 would be a symlink to aha0b0t0d0, and you can do
> "ls" and find out what is linked to what. The 4th part
> can be solved by allowing the sysadmin to create symlinks
> in devfs. The network driver subsystem would obviously have
> to be changed to consult devfs for the device names.

This is essentially the solution that Sun adapted for Solaris. Note
that the mapping from "logical" names to "physical" names needs to be
fixed, so that you might have a system with disk1 and disk2, but no
disk0 because it's been removed.

The major problem with it is that todays bus architectures don't have
stable device addresses. Instead of devices having a fixed address on
the bus that the user sets, the addresses are assigned as the devices
are discovered. This is pretty much a requirement if you want to sell
hardware to 12:00 flashers. While that's not the market that FreeBSD
deals with, it is the hardware that FreeBSD runs on.

The other problem is that not all devices that need names have entries
in /dev. While that's fixable, different solutions will be optimal for
different kinds of devices anyway, so we may not want to fix it.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.