Re: udev and devfs - The final word

From: Andries Brouwer
Date: Mon Jan 05 2004 - 09:56:44 EST


On Sun, Jan 04, 2004 at 07:33:16PM -0800, Linus Torvalds wrote:

[A mailbox full of messages, too many to reply to.
Yes, Daniel Jacobowitz understood that I referred to fsid in the NFS case:

There is a great variation here in what various servers and clients do,
but roughly speaking filehandles tend to contain a fsid, and this fsid
often (no fsid= given) involves (major,minor,ino).

No, I have not talked this year about exporting /dev. Also interesting.
Yes, as I said, one can avoid NFS problems by giving fsid=.
It is similar elsewhere. A thousand minor problems are caused by
unstable device numbers. All annoying, each can be solved easily
once one has figured out what goes wrong and why. That is why I say
"preferably stable across reboots".]


What remains to be said?

Linus, let me try a bit more to address what I see as a misconception
in your posts.

> It shouldn't be fixed by saying "device numbers have to be stable across
> reboots", because the fact is, we're most likely going to have storage
> that is really really hard to enumerate in a repeatable fashion.

You have this strange hangup concerning "enumerate", and then keep
repeating to others that enumerating is impossible, and that therefore
stable device numbers are impossible, and that consequently, since we
cannot have stable device numbers expecting them to be stable is broken.

It is an old misconception - I recall you telling me how many billion years
an "ls /dev" would take with 64-bit device numbers.

No - I never advocated "find a device number by enumeration".
Quite the opposite, I advocated "use a hash of the serial number
as the device number of a disk". And more generally, "it is the
driver's job to assign a device number".

So it is not difficult at all to give this network attached storage
a stable device number.

And if one can, there is no reason not to do so.
It may even allow udev to give stable names as well.


Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/