Date: Tue, 21 Feb 95 10:37:57 GMT From: "gj%pcs.dec.com@inet-gw-1.pa.dec.com" <garyj@rks32.pcs.dec.com> To: current%freebsd.org@inet-gw-1.pa.dec.com Subject: Re: ATTENTION Message-ID: <m0rgryf-0005PMC@rks32.pcs.dec.com> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> of Tue, 21 Feb 95 21:02:13 X.
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans gives several good reasons why the compatibility cruft is needed [deleted] I have to agree with Bruce, it's very important in my eyes to make a slow transition to the new slice code until the kernel is 100% stable. If a user makes the full transition running an older kernel and then moves to a new one only to discover that there's some bug which prevents a successful boot, he's pretty much up the creek. His old backup kernel won't understand the new slice stuff in fstab and /dev. If, on the other hand, he uses a new kernel (with the old stuff in fstab and /dev at boot) to do the transition and then somehow the slice code doesn't work, he's just as far up the creek. Of course, there's no reason why the old and new devices can't co-exist in /dev until everything's been shaken out. But this still leaves the fstab problem. A new install using the slice stuff shouldn't be a problem, since everything get's installed from scratch (assuming the new slice code has really been wrung out). I realize this is sort of a chicken and egg problem, since somebody has to test the new code. Since I have two systems I'm more than willing to act as guinea pig. Not to imply that Bruce hasn't thorughly tested the new code. Gary J.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0rgryf-0005PMC>