Accessing disks via their serial numbers.

[Poul-Henning Kamp]

In message <20060627.103343.-432837786.imp at bsdimp.com>, "M. Warner Losh" writes
:

>: devfs is not a hardware inventory facility, it is magic place for
>: performing a rendez-vous with a device driver.
>
>True, but somewhat irrelvant.

Not really, it has to be kept in mind to avoid decending into the
hell currently reserved for Linux procfs :-)

>True, but somewhat irrelvant.  This does not go to the question that I
>asked.  What problems does having fully enumerated devices cause?

There is no problem with fully enumerated devices, as long as
they don't cause an explosion in the number of devices.

>devfs does allow directory listings, therefore absent some compelling
>reason to the contrary these listings should be complete.  This is an
>enumeration of the available devices, which closely mirrors the
>available hardware.

The problem is that it exactly doesn't do that, and can't possibly
do that, because hardware is not seen by devfs until the driver
is loaded.

I realize that this sounds a bit Clintonesque, but it all comes
down to what your definition of "available" is.

For instance, the crypt-hw support has one joint device node in /dev
but can cover up 16 cards, without ever disclosing to you what
they are or what they can do, until you open the joint device and
ask with the right ioctls.

>There are other facilities for finding out the
>underlying hardware, but there's no way to find the magic names in
>/dev easily.

Only whatever convention we decide to use to pick the names them
can help you there.

>While it is a magic place, that magic place exists in
>the context of a file system, and file systems aren't supposed to
>randomly open files.

You lost me there...

>It is also a security concern.  If I wanted to have non-default
>permissions on these magic nodes, at the very least I'd have no way to
>audit them.  I'm unclear if doing the normal unix operations on the
>magic nodes would suffice.

We have the devfs(8) rules for that.

>My question is more specific.  What is wrong with having
>entries in devfs of files you can actually open, when we know the
>universe that is possible given the current knowledge of the kernel?

We generally have that.

The only exceptions I'm aware of right now are pseudo devices, for
which precreation doesn't make sense at all.

>My big problem with magic files and hiding them is that it becomes
>difficult or impossible to diagnose and troubleshoot.

I have a very big problem with magic files as well.

Currently g_label doesn't impose any restrictions on the label
strings of the device, which means that you can include '/', '..'
and ';' in labels.  I don't need to tell you what that means
for shell scripts etc.  Put a g_label on an USB key and trick
the admin into to doing something stupid and you're all set:

	just type 
		mount -t msdos /dev/da0*
	I can't remember which slice it is...


The reason why I am advocating using "on-demand" names for
what Pawel is proposing is that way the names only exist
if people ask for them, and only the names they ask for exists.

In addition to avoiding a wanton doubling of the geom mesh
size (because he does it at the very bottom) that also
adds significant flexibilty and security to the table.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.