[lkml]   [1999]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: UUIDs (and devfs and major/minor numbers)
In message <Pine.LNX.4.05.9906190814310.26257-100000@mhw.ULib.IUPUI.Edu>, "Mark
H. Wood" writes:
| On Thu, 17 Jun 1999 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

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]
system administrator [WAY too many hats]
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean