Apparently I was confusing, because people are (apparently) disagreeing with
what I wrote but agreeing with what I meant to say. Essentially, all I said
was that the choice of logical volume management by label or UUID has no
effect on the desirability of devfs (except that devfs may make
implementation a little easier). And that the magic word "policy" that's
being thrown around as a reason not to like devfs just doesn't apply.
(After all, what can be more mechanism than "the disk obtained at LUN 0 on
ID 2 on the second SCSI controller?) Hope this clarifies a bit.
Richard Gooch wrote:
> Firstly, devfs preserves the old names. So you have the choice.
Yes, I know -- I was over-simplifying wrt device names, because it wasn't
relevant. I definitely wasn't saying a thing about the specific choice of
device names themselves made by devfs (although if you ask, I think the
devfs naming scheme makes tons more sense).
> Secondly, it probably makes sense to implement a nice volume
> management scheme based on devfs+devfsd.
That was essentially my point. Except that I wasn't thinking about
specifically a scheme of using devfsd to manage volumes; I was looking more
at looking up the UUID or label from all available disks as it is needed.
> > 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? [...]
>
> Devfs supports sockets. You just create them from user space. It
> doesn't cost anything extra, as sockets (and pipes) are just treated
> as inodes to store. So even if you abolished sockets and pipes in
> /dev, it wouldn't mean the devfs per-inode storage requirements would
> be decreased.
Yes, I realize that; and just after I sent this mail I realized that this is
unnecessary given a persistence scheme for devfs. The only problem I hoped
to solve was the need to create sockets for init, which sometimes need to be
created before init actually starts. So forget I said that; just a random
thought.
> Yuk. HTML mail.
Ack! Sorry, I didn't realize that was happening; should be fixed now.
Chris
-
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/