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

Daniel Taylor (dante@plethora.net)
Fri, 18 Jun 1999 15:22:51 -0500 (CDT)


On 18 Jun 1999, H. Peter Anvin wrote:

> Followup to: <Pine.LNX.3.96.990617172848.17421E-100000@cu.mol.plethora.net>
> By author: Daniel Taylor <dante@plethora.net>
> In newsgroup: linux.dev.kernel
> >
> > If there is no policy involved in syscall numbers, Major/Minor assignments
> > and /proc entries, THEN THERE IS NO POLICY SET BY DEVFS EITHER.
> >
> > C'mon guys, some consistency in the opposition at least.
> >
> > Daniel Taylor
> >
>
> Actually, there is. The /dev directory is a mapping table between the
> kernel interface (as well as providing a store for permissions), and
> devfs removes this.
>
Correct, a mapping table that requires human management to ensure that
it is accurate, up to date, and contains no superflous entries.
The very need for the aformentioned mapping table is: POLICY!
The policy is to provide the device information from the kernel in
a format that requires _other_ bits of kernel code (the filesystem)
to interpret.

I repeat (again):
The kernel provides access to devices, the kernel sets policy.
To claim otherwise is folly.

The policy that devfs allows is:
a. more flexible
b. more robust
c. easier on troubleshooters
d. reliant on kernel code in fewer places
e. more elegant (IMHO)
f. independent of the root filesystem type

You may disagree with me on any of these particulars,
but I want to see some sort of hard evidence that there is
a better way. Like running code.

> The equivalent level of indirection for syscall numbers is libc.

Correct, and so we have /proc. Shell scripts have trouble
linking libc. With all of this information presented as
files there is a lot you can do with kernel+bash+fileutils+textutils
that just wasn't possible a short time ago.

Daniel Taylor

-
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/