Date: Mon, 21 Aug 95 21:58:04 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: msmith@atrad.adelaide.edu.au, bde@zeta.org.au, freebsd-hackers@FreeBSD.org, roberto@keltia.frmug.fr.net Subject: Re: Install issues (was: State of the union speech Message-ID: <9508220358.AA28423@cs.weber.edu> In-Reply-To: <199508220309.NAA20592@godzilla.zeta.org.au> from "Bruce Evans" at Aug 22, 95 01:09:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >What we are interested in is a sector offset and length on the physical
> >device being exported as a device to the /dev namespace. This is different
>
> I.e., a slice.
>
> >This actually strikes at the heart of what I think is wrong with the
> >current disklabel code.
>
> You mean the current slice code. Disklabels are layered under slices
> so they are irrelevant to this discussion. I think labels should go
> away eventually.
I agree on the label's wanting to "go away". But I think that since
the disklabel is on a logical physical device, it's important; that's
because the disklabel is the critter that exports the terminal device that
is represented as a logical array of disk blocks and that's where the
file systems go.
This is exactly what he wants to do, it's just that a filesystem goes
on the logical physical device and gets mountes as well.
Whole disk:
[][ ][ ]
^ ^ ^
| | |
| `-- DOS partition(3) `-- BSD partition(2)
`-- DOS boot + partition table(1)
BSD partition:
[][ ][ ][ ][ ]
^ ^ ^ ^ ^
| | | | |
| `-- slice a(3) `-- slice b(3) `-- slice c(3) `-- slice d(3)
`-- disklabel
DOS partition:
[ { } ]
^ ^
| |
| `-- contiguous area(4)
`-- partition start
(1) physical device file
(2) logical physical device
(3) mountable device
(4) area reexported as a mountable device
In effect, the FAT and the DOS directory lookup is replacing the BSD
disklabel in terms of how the area is made known to the system.
> The current slice code is too closely tied to a particular
> initialization routine (the only one implemented).
8-).
> >The PowerPC under a PReP/OpenFirmware implementation assumes a DOS
> >partitioning scheme, but uses the sector offset field rather than the
> >C/H/S field -- 4GB worth of 512 byte sectors, or 2TB of disk.
>
> So does FreeBSD.
>
> >They look for the AA55 signature, and if it isn't present, they assume
> >that the physical device constitutes a single partition. This is their
>
> So does FreeBSD. This doesn't work too well in practice, since some
> BIOSes require AA55 for booting, so the default bootblock has to have
> it, so you get an unwanted signature when you write the bootblock.
The first sector (512 bytes) is what PReP refers to as "the
compatability block" of the disk. They stuff a partition ID of 0x41
in there to indicate OpenFirmware, and allocate the patition in a DOS
partition entry. But the boot process pretty much ignores it from
that point on. The next 512 bytes (the first 512 of the 0x41 partition)
are used to dictate load image, etc to the firmware. Clearly, this
is where the BSD specific boot code goes for BSD, but for OpenFirmware,
it's where the information for loading the remainder of the image
resides.
This is actaully a very clean implementation.
The point I was making, though is that they assume this on *every* disk,
even floppies. If it has the signature, it has a partition table on
it, wierd as it may seem to have a floppy with a partition table. The
reason for this is uniform treatment of devices. Which is what I'm
advocating.
On PC hardware, probably we want to always have two boot blocks: the
BSD boot block and the system boot block with the partition table in
it to make the BIOS happy. I know that the curent code is set up to
handle the case of *just* a BSD boot block -- what I'm saying is that
this probably isn't a good idea.
It *is* a good idea for non-PC hardware -- or rather, whatever is native
to the platform is a good idea. The intial boot is dependent on the
native firmware for the BOX. For a PC, this is the MBR with the DOS
partition table in it.
In general, it's necessary to abstract the difference between terminal
devices, which are allowed to have file systems on them, top level
devices, which are there to make the firmware happy, and intermediate
devices which implose a "slicing" or "partitioning" scheme, or which
can export a subsection of a terminal device as a terminal device or
as additional intermediate devices.
This approach has the advantage of working for the existing partition
and slice handling, the vnconfig device, AND the exportation of a
contiguous chunk of disk as a device AND extended partitions, all
without ruining the distintions in the kernel that cause some of the
current install problems (ie: WD1007).
Terry Lambert
terry@cs.weber.edu
---
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?9508220358.AA28423>