Firstly, devfs preserves the old names. So you have the choice.
Secondly, it probably makes sense to implement a nice volume
management scheme based on devfs+devfsd. Whether that functionality
should be put into devfsd or into scripts that devfsd calls is an open
question. I have not formed an opinion on that at this stage.
> 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)
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.
Perhaps you thought that devfs creates the sockets? That is definately
not the case.
> ------=_NextPart_000_0076_01BEB735.28BE6A70
> Content-Type: text/html;
Yuk. HTML mail.
Regards,
Richard....
-
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/