Date: Fri, 13 Dec 1996 12:42:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 2.1.5-R kernel root on sd0 fails Message-ID: <199612131942.MAA15651@phaeton.artisoft.com> In-Reply-To: <199612130929.KAA17585@uriah.heep.sax.de> from "J Wunsch" at Dec 13, 96 10:29:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > >No, it ain't broken. The root device is _intended_ to be > > >automatically changed to the device where the system has been booted > > >from... > > > > It would be nice if the entries in /etc/fstab for the boot device were > > automatically changed. I keep a backup root file system on a removable > > (zip) drive and the drive number is often wrong when I need it. > > This is a chicken-and-egg problem, isn't it? The root file system > must be mounted first (and _that_'s the operation that fails), in > order to change the fstab. > > Changing the fstab could perhaps be made by some clever trickery in > /etc/rc, but it's certainly not easy to cover all cases. The fstab could be changed to a "mapping description" file instead of a "mount these FS's" file. This would require assigning a resource ID to each device (we could call such an ID a "label" 8-) 8-)). The probe code would find the devices and call back into the FS code with "device arrived" events. The same events could be used for removable media (like JAZ, Zip, and Syquest drives, CDROMs, floppy disks, and PCMCIA "Flash" cards). This requires having an "arrived device structure" (we could call it "struct mount" 8-) 8-)). This would require changing the mount list structure such that "the root device" is a logical, rather than a structural abstraction. This means on process fork, the chroot fd would need to be set to the parent chroot fd in the proc structure; for init, the value would be preinitialized to the "root" FS. The namei() code would have to be changed to make the root/chroot code distinction "go away". This would simplify the namei() code. In order to create a mount structure for a device, you would need to process the device arrival. You would do this by asking each FS if they "wanted" the FS (ie: call each FS specific mount() from the FS vfsops structure, and when it returns 'true', quit calling). So what do we end up with? Automatic mounts of all devices into "volume" decriptors -- "struct mount". *THEN* when the system comes up, it maps the mount by volume ID into vnode covering (incidental to this, the "exports" and "mount point covered" processing moves into common code, and doesn't have to be reimplemented for each FS type -- the kernel size goes down at the same time the reliability of the process goes up). *THEN* your "chicken and egg" problem simply "goes away". A side effect of this is that we win immediate support for transient resources using the POSIX name space escape "\\volume_label\..." relative root using symbolic links... voila', support for nomadic computing for transient network connectivity with software packages as sharable resources. Luckily, I submitted the code to do all this in June of 1995. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612131942.MAA15651>