Re: UUIDs (and devfs and major/minor numbers)

Brandon S. Allbery KF8NH (allbery@kf8nh.apk.net)
Sat, 19 Jun 1999 10:14:09 -0400

In message <Pine.LNX.4.05.9906190814310.26257-100000@mhw.ULib.IUPUI.Edu>, "Mark
H. Wood" writes:
+-----
| On Thu, 17 Jun 1999 tytso@mit.edu wrote:
| [much useful argument, snipped]
| > The issue is not virtual FS versus some other kernel interface. The
| > issue is what appears in /dev, and whether the kernel code should be
| > hard coding what happears in /dev. It shouldn't. That's policy. The
| > kernel shouldn't be dictating policy.
| >
| > Instead, the kernel should be exporting sufficient information so that a
| > user-mode daemon can provide whatever interesting naming scheme (and
| > that naming scheme might include device names based on the UUID or the
| > fslabel in the ext2 device, or something else far more general than what
| > kernel-space code can provide.)
|
| it works well. The kernel does pick a (simple) structure for names, a
| structure that does not please everyone but is at least consistent and
| fairly cheap. The kernel also provides a generator function,
| SYS$GETDVI(), which will produce one-by-one the names of all the tape
| devices, or all the disks on cluster node FOO, etc. It doesn't cover bus
+--->8

Someone please explain:

(1) why exporting this information from the kernel in the arguably most
useful form --- a virtual filesystem --- is more evil than exporting it
as e.g. a /proc file or a generator sysctl();

(2) why devfs detractors all think devfs somehow *has* to be mounted on /dev,
when clearly it doesn't (and it's IMHO even more useful when mounted on
/devices, with a devfsd / vold to tend to hot-swappable devices).

(And (2a) I'd like to know why hpa asserted that "devfs is only useful if
everyone uses it and mounts it on /dev" (paraphrased). Huh? I missed
something, apparently.)

At this point I'm pretty sure that the devfs boosters and detractors are
arguing past each other and nothing's going to be accomplished until they're
both talking about the same thing.

-- 
brandon s. allbery	[os/2][linux][solaris][japh]	 allbery@kf8nh.apk.net
system administrator	     [WAY too many hats]	   allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering			 KF8NH
     We are Linux. Resistance is an indication that you missed the point.


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