At Sun, 21 Jun 2009 20:53:59 -0400 (EDT), der Mouse
<mouse%Rodents-Montreal.ORG@localhost> wrote:
Subject: Re: FreeBSD devfs support on NetBSD 5.0
>
> > I.e. rename() always just fails on my ideal devfs.
>
> That's a substantial enough regression compared to what we have before
> that I for one would consider the result unusable. (At least assuming
> you're talking about the /dev finally presented, as opposed to the
> devfs underlying the union thingy.)
I think given further reading about mount_union(8) and white-out files I
believe the upper layer can easily fully support rename(2) (and
everything else) at least as well as mount_union(8) does, and that
should be quite adequate.
Indeed the underlying devfs layer would not necessarily have to support
rename(2) (though it easily could using the same white-out files, just
not with cross-boot persistence), but perhaps unlink(2) and mknod(2)
could actually be used (the latter in some slightly modified way
perhaps) as one possible method to control device removal and
attachment.
> So you're also proposing to do away with the ability to have plain
> files and non-fast symlinks in /dev?
Indeed. If you want those then you have to use the union overlay FS.
(that's more or less the way it works in every other unix-like system
I've ever seen with a dynamic devfs kind of feature)
(well the non-fast symlinks could be supported, just without cross-boot
persistence of course)
However I personally think anyone who ever wants to put a regular data
file in /dev (even MAKEDEV!) needs a new file put in their head to
remind them that it's really not a good idea to corrupt the hierarchy
goals in such dangerous ways. Existence of regular data files in /dev
is, to me, sure evidence that there's some major bug somewhere, either a
missing device file (perhaps because it was removed by a buggy program),
or a program has written to a non-existant device file. I must say I've
seen a full bit-bucket (i.e. /dev/null is a file that fills the
filesystem) crash machines far too often to ever allow any deviation
from this rule. I have scripts and monitoring programs to find and
shout loudly about such things. If a side-effect of use of devfs is
that no regular file can ever exist in /dev, then that's "A Very Good
Thing!(tm)".
(of course there's no technical reason why defvs couldn't be just an
extension of tmpfs or mfs and thus allow for non-persistent storage of
data too)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgplRZrqBdi4k.pgp
Description: PGP signature