Date: Sun, 31 Dec 2006 20:41:04 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Tim Kientzle <kientzle@freebsd.org> Cc: freebsd-hackers@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de> Subject: Re: Init.c, making it chroot Message-ID: <20061231203829.O7974@fledge.watson.org> In-Reply-To: <45981346.3050201@freebsd.org> References: <200612301119.kBUBJNno062104@lurza.secnetix.de> <20061230123256.V18740@fledge.watson.org> <45981346.3050201@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Dec 2006, Tim Kientzle wrote: > Robert Watson wrote: >> ... It used to be that only certain file systems could be used as a root >> file system, because only they knew how to bypass the lookup procedure to >> find their device node, short-circuiting to the in-kernel device list. > > So why are the MD_ROOT and NFS_ROOT options still around? It sounds like > there must still be something special about root-capable file systems. NFS_ROOT has to do with extracting the root mount configuration information from the interface list, loader environment, prior to the file system mount process so that NFS knows where to go to find a file system, configure networking, etc. MD_ROOT has to do with setting up the md device to mount the root file system from in memory without having mdconfig run. A glance at the md(4) source code suggests that it also tweaks the default root device to be "ufs:/dev/md0". This is not actually a file system option so much as an option in the behavior of the md(4) device driver. At least, this is my understanding from a very casual glance at the source. In both cases, we now use the single vfs_mount VFSOP. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061231203829.O7974>