Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Feb 1995 21:02:13 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, jkh@freefall.cdrom.com
Cc:        current@FreeBSD.org, obiwan!bob@uudell.us.dell.com, phk@ref.tfs.com, roberto@blaise.ibp.fr
Subject:   Re: ATTENTION
Message-ID:  <199502211002.VAA12502@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> The slice code will be mandatory but you won't see much evidence of
>> it.  However, there is a lot of compatibility cruft to make the old
>> devices work transparently.  I'd like this to go away soon.  Devices

>Well, as far as I'm concerned the flag day has already been called
>and we can just do this in one jump.  Slow transitions can be just
>as bad or worse than jumps, in my experience, and I'm keen to see this
>go forward so that we can start relying on the slice code for the new
>installation code.

Removing the compatibility cruft would cause the following problems:

- almost all disk labels would have to be changed.  Old versions of
  FreeBSD wouldn't be able to read new labels and vice versa.  (Even
  with the compatibility cruft, other BSD's will have problems reading
  FreeBSD labels if more than one FreeBSD partition is used.)
- all disk devices in /dev would have to be removed and rebuilt.
- almost all disk devices in fstab and config would have to be renamed
- the device name changes aren't backwards compatibile either.  They
  are easier to back out than the label changes iff you can find a
  compatible kernel to boot from.
- all backups of /dev would have to fixed to not use a crufty program/
  format such as tar, pax or the default cpio.  I forgot to say that
  they will need to be fixed anyway.  The following backup programs/
  formats work right: dump, `cpio -newdc'.

I think making all these changes together is too much.  It would be
too hard to install them automatically without a complete reinstall.
The compatibility cruft hides most of the interface changes so there
is little to worry about except bugs (bugs are most likely in the
compatibility cruft since it was written last :-).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502211002.VAA12502>