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>