Skip site navigation (1)Skip section navigation (2)
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>