RE: devfs again, (was RE: USB device allocation)

Jakma, Paul (Paul.Jakma@compaq.com)
Fri, 8 Oct 1999 15:25:11 +0100


> 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).

arghhhh... horst, devfs supports ownership, names, links, pipes, etc just
like normal ext2 /dev... and persistence via a daemon. IIRC the only
difference between
devfs and ext2 /dev is that devfs bypasses VFS.

you've been told this already.

> Note that just devfs does _not_ solve the "more devices"
> problem, as long
> as major/minor stay limited.

it does solve it. As devfs can allocate major/minors dynamically at
run-time, rather than the old way of having to pre-allocate major/minors to
all possible permutations of devices.

you've been told this already.

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

devfs solves this perfectly. the reason being that the driver does know at
runtime which disk is on which controller/bus/id/lun. And so the driver can
register disks with appropriate names like c0b1t2u0.. etc.

this has been stated already.

> Any solution it
> could offer for this

[ above slightly out of context ]

ok, rather than just saying "no.. no.. no..". Why can't we have a
constructive argument where you say "no, you'd probably need to do it
something more like xyz".

regards,

Paul Jakma.

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