Date: Wed, 29 Mar 2000 08:05:39 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, chris@calldei.com, freebsd-arch@freebsd.org Subject: Re: Proposal: Union mount of fdesc on top of /dev Message-ID: <Pine.NEB.3.96L.1000329075805.28331A-100000@fledge.watson.org> In-Reply-To: <xzpg0tbxoa9.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Mar 2000, Dag-Erling Smorgrav wrote:
> Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
> > In message <xzpsnxbxor2.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes:
> > > Anyway, since /dev/std* never change, how about having fdesc *only*
> > > handle the /dev/fd/* stuff, so you can (non-union) mount it on /dev/fd
> > > and let /dev/std* be either symlinks to /dev/fd/[012] or plain old
> > > static device nodes like they're now?
> > Symlinks have my vote.
>
> The downside is they'll be broken if fdesc isn't mounted...
I consider this to be a relatively serious impediment to a number of the
``make it a file system'' solutions--they aren't mounted when you boot to
single user mode, and if you're booting to single user mode due to some
sort of failure, you may not be able to mount them during the recovery.
Now, presumably few tools depend on /dev/fd/ (?), but tools relying on
/dev/std{in,out,err} are more likely. Similarly, a strong argument for a
sysctl management interface is that mounting a /kernfs is much less likely
to succeed in the event of failure :-). Not having to mount procfs to get
accurate information about processes is also useful.
In the jail case, it would be nice to minimize the number of mountpoints
per-jail (if only to maintain the usefulness of using df or mount to
inspect the current mount configuration :-).
The upgrade case is also useful to consider--there have been a number of
times where I have upgraded my kernel, but not my /modules. This is easy
to do as the building of /modules is tied to world, not kernel building
(?). However, especially with modules like nfs.ko, it's very easy to end
up with a panic if the modules and the kernel are out of synch. Being
unable to mount /dev/fd or /dev due to an out-of-synch kernel makes the
whole system more fragile and less tolerant of user misbehavior
(accidental, due to another failure, or intentional). At the very least,
this would be a strong argument for placing the requisite synthetic file
systems in the kernel itself, not in modules.
Just some thoughts..
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000329075805.28331A-100000>