Linux-Kernel Archive: Re: UUIDs (and devfs and major/minor numbers)

------=_NextPart_000_0076_01BEB735.28BE6A70
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This isn't a direct reply to anyone; just getting a thought out there. =
It seems like most of the objection to devfs has been to its use of bus =
locations rather than logical identifications of a disk in locating =
them. But is it really any more difficult to build a logical volume =
view of the disks in a system on top of devfs than it is to do the same =
on top of a physical dev filesystem? Actually, I would think it's =
easier, since programs like LILO just have to check devices that are =
actually present for that UUID.

I think the ultimate hypocrisy (sp?) in this discussion is that a lot of =
people are saying that policy should be kept out of the kernel, but then =
criticizing devfs for not handling policy. UUID's, volume labels, and =
so forth are definitely policy. They can be handled in user space, and =
in some cases, despite a static dev filesystem being a poor abstraction =
to build on top of, applications do handle them at user-level. Names in =
the dev filesystem are NOT policy. They have just been used that way =
because any appropriate policy does not exist.

So how about we stop criticizing devfs for what it doesn't do, and =
instead start thinking about how it improves what we have right now.

PS. Maybe I missed this in the Union FS discussion, but has anyone =
thought about the implications of unionfs in solving some of the =
remaining hacks in devfs? Take, for example, required sockets for init. =
Just a thought for the future. (Although from a purist perspective, =
which I admit to occasionally holding, I'd say we probably ought to =
start changing init programs to not use sockets in /dev -- that seems =
like a poor place for such a socket)

------=_NextPart_000_0076_01BEB735.28BE6A70
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This isn't a direct reply to anyone; = just getting a=20 thought out there. It seems like most of the objection to devfs = has been=20 to its use of bus locations rather than logical identifications of a = disk in=20 locating them. But is it really any more difficult to build a = logical=20 volume view of the disks in a system on top of devfs than it is to do = the same=20 on top of a physical dev filesystem? Actually, I would think it's = easier,=20 since programs like LILO just have to check devices that are actually = present=20 for that UUID.

I think the ultimate hypocrisy (sp?) in = this=20 discussion is that a lot of people are saying that policy should be kept = out of=20 the kernel, but then criticizing devfs for not handling policy. = UUID's,=20 volume labels, and so forth are definitely policy. They can be = handled in=20 user space, and in some cases, despite a static dev filesystem being a = poor=20 abstraction to build on top of, applications do handle them at = user-level. =20 Names in the dev filesystem are NOT policy. They have just been = used that=20 way because any appropriate policy does not exist.

So how about we stop criticizing devfs = for what it=20 doesn't do, and instead start thinking about how it improves what we = have right=20 now.

PS. Maybe I missed this in the Union FS = discussion,=20 but has anyone thought about the implications of unionfs in solving some = of the=20 remaining hacks in devfs? Take, for example, required sockets for=20 init. Just a thought for the future. (Although from a = purist=20 perspective, which I admit to occasionally holding, I'd say we probably = ought to=20 start changing init programs to not use sockets in /dev -- that seems = like a=20 poor place for such a socket)