>> I don't think we want to complain that devfs is at fault for the fact
that
>> sudo access can be dangerous.
>What I want to say is that your "solution" creates more problems than there
>were before. The Unix way (/dev is part of a real filesystem; permissions,
>ownership, names, links, ... all work the same as with regular files) is a
>time-tested design. Not flawless, but its flaws are known and workarounds
>are in place. You propose to junk all that for a shiny, new way of doing
>things that does break in many ways (see above). All for the tenuous
>purpose of being able to address more devices (get a bigger dev_t, and be
>done) or being able to fool around all day plugging/unplugging devices.
I propose to junk nothing, as no one does. I do, however,
see a bunch of problems stated thusly:
- inability to summarize devices (and their interfaces)
recognized by the kernel from userland unless extensive
probing is done by a lock grabbing program.
- Inflexible major/minor restrictions that are
unsustainable unless increasing dev_t which has
implications in and outside the kernel
- Horendous userland hacks in order to be able to
use hot plug devices. PCMCIA, USB
- Lack of an extremely dynamic runtime device
scheme, needed to support USB and PCMCIA to
a lesser extent
- Devices named serially such that if one from in
the middle is removed, all subsequent devices must
be addressed differently. As stated before, UUID
solutions only work on FSes with UUIDs, or things
that even USE an FS!!!
- Others I can't even think of right now.
And ONE, count 'em, ONE clean solution, or at least the cleanest one
to date, and it based on solid foundation, whatever anyone has to
say about it's implementation, which, is indeed the least intrusive
I can think of!
>Note that just devfs does _not_ solve the "more devices" problem, as long
>as major/minor stay limited. It can't really solve the "unplug sda, now sdy
>is sdx" problem either (somehow devices _must_ be named, and this has to be
>done somehow fixed, you can't just lug around the whole history of /dev),
>and it can't solve the "unplug sdc, plug in another sdc, and then sdd; now
>plug in the old sdc and have it be sdc again" problem. Any solution it
>could offer for this is useless: I'd much prefer to be able to go and look
You are so completely wrong here, it's as if you've never heard of
SYSV style device naming conventions. It's defacto standard. Suffice
it to say that location based naming schemes are the only way to go.
UUID is arbitrary, and, is therefore a HACK.
>for /dev/disk-<some-serial-number> to check which <serial-number>s I've
>used, and not having to remember that by my own because that particular
>disk (out of the hundreds advocated by you) just so happens not to be on
>line ATM. You want to unclutter /dev cluttering me.
I don't get what you're saying here.
>BTW, the "devices get renamed" problem _is_ solved, and has been for quite
>some time: You can mount by disk label or uuid, forget about the device
name.
Wrong, as explained above. What about raw (well, at least
non-fs) volumes??? Please address even ONE of my points.
-Shawn
-
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/