From owner-freebsd-hackers Mon Aug 21 20:56:57 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id UAA00314 for hackers-outgoing; Mon, 21 Aug 1995 20:56:57 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id UAA00307 for ; Mon, 21 Aug 1995 20:56:55 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA28423; Mon, 21 Aug 95 21:58:05 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508220358.AA28423@cs.weber.edu> Subject: Re: Install issues (was: State of the union speech To: bde@zeta.org.au (Bruce Evans) Date: Mon, 21 Aug 95 21:58:04 MDT Cc: msmith@atrad.adelaide.edu.au, bde@zeta.org.au, freebsd-hackers@FreeBSD.org, roberto@keltia.frmug.fr.net In-Reply-To: <199508220309.NAA20592@godzilla.zeta.org.au> from "Bruce Evans" at Aug 22, 95 01:09:36 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > >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.