Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!basser.cs.su.oz.au!news.cs.su.oz.au!metro!seagoon.newcastle.edu.au!wabbit.cc.uow.edu.au!dmssyd.syd.dms.CSIRO.AU!dmsperth.per.dms.CSIRO.AU!uniwa!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!spool.mu.edu!olivea!charnel!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.development Subject: Re: fdisk Date: 8 Feb 1994 05:22:30 GMT Organization: Weber State University, Ogden, UT Lines: 226 Message-ID: <2j77im$a0h@u.cc.utah.edu> References: <0hI0M_u00WB7EC5GkR@andrew.cmu.edu> <jmonroyCKupzM.4sz@netcom.com> NNTP-Posting-Host: cs.weber.edu In article <jmonroyCKupzM.4sz@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes: [ ... re: disk geometry and setup ... ] > The truth (as I see it) is half these guys don't > know what the hell their talking about and > they mostly like to dabble in political poking > (i.e., my stick is prittier than yours so mine > is the prittiest.) > > Hog wash. > > Terry can the closest to a real answer, but > still let out a few things. Well, the person wanted to get running, not make the code changes that are necessary for everything to "just work". Since you neglected to state what you felt I left out, I'm going to feel free to tell you what *I* feel I left out, and you can add to the list post-facto as you see fit. The first thing I left out is that none of the BS I described should ever have been necessary in the first place; it's the result of either poor initial understanding of the boot process by the original authors, or simple expediency on their part. I will state that I believe Bill Jolitz was being expedient, and that no one has taken the time to go back and correct this "The Right Way"(tm). The second thing I left out was a definition of "The Right Way". If you have followed either the FreeBSD-hackers mailing list, or these news groups (actually, I believe I had an almost 100% solution to the problem as far back as comp.unix.bsd -- and posted it there), you will know what I think should be done; however, for the edification of the few who have not yet seen the list, I repeat it here. The following is an almost verbatim (I have made some corrections) repeat of a previous posting on this matter: ==BEGIN INCLUDED TEXT====================================================== = 1) There should always be a DOS-style Master Boot Record on Intel = based BSD hard drives. This reduces the "does it or doesn't it" = questions to "what does it have in it. It also allows BSD to be = installed first and then DOS (or OS/2 or NT or Linux) to be = installed later without causing problems. I personally nominate = the OS-BS program for this, since it supports booting from second = drives and does not have GPL restrictions. = = 2) The boot blocks need to be modified to pass additional information = in to the kernel. This information will be used during install, = partitioning, and non-BSD FS mounting (ie: DOSFS/PCFS). It should = be retrieved prior to entering protected mode using the int13 ah=8 = BIOS call in the secondary (DOS partition specific) bootstrap. = = a) The BIOS apparent geometry (see pfdisktc sources and = ide_conf sources for the BIOS calls to get the translated = geometry). This information needs to be used by the = fdisk program under BSD to ensure the C/H/S parameters = given to DOS for the BSD boot code to be located by the = DOS MBR (the values placed in the DOS partition table = for a BSD partition). = = b) The inode number of the UFS inode that is used as the = kernel, plus the kernel name need to be passed, so that = standard utilities can have a call to get the name (I = do not agree with linking the inode into the /kernel = FS as a locked vnode is sufficient -- the "kernfs" is = something that should NOT be mandatory). The inode = number alone is sufficient to locate the kernel if the = kernel is limited to a location on "/", the name is = needed if the boot code is changed to be able to locate = a kernel by path in a subdirectory of a UFS FS. = = c) The BIOS apparent geometry for secondary devices should = be passed to the kernel as well, so that non-BSD partitions = on them can be mounted as well (in addition to providing = a uniform disk layout mechanism for all disks, instead of = making a distinction between "boot" and "other" disks). = = 3) The kernel initialization needs to be changed to accept these = parameters and store them in a safe copy location (since the = logical place to pass them is in an unitialized data area, such = as the bounce buffers). This requirement may be relaxed for any = other mechanism which will suffice to pass the information in. = = 4) The kernel disk drivers need to be modified to provide a "get BIOS = apparent geometry/get geometry" ioctl() which can be applied on a = per device basis. = = 5) The fdisk and disklabel programs need to be modified to use the = geometry information automatically -- by making the ioctl() calls. = The BIOS apparent geometry is necessary for the C/H/S values in the = DOS partition table, and is also necessary for the C/H/S values = in the disklabel, which must be labeled in the translated geometry = to allow the second stage boot to find the BSD partitioning data; = the sector count is geometry independent. = = Known "gotcha"'s: = = 1) For disks that aren't recognized by BIOS (such as would occur with = a Adaptech SCSI controller with BIOS disabled in a machine where = the primary boot device is an IDE drive (the SCSI BIOS being disbled = to allow the IDE drive to be the boot device by imposing its own = BIOS): = = a) The BIOS apparent geometry for the second disk without the = enabled BIOS will be unknown, since it is imposed by a = DOS driver which is loaded from the config.sys on the IDE = drive to allow it to be accessed by DOS. Such a device = must be treated as if the BIOS apparent geometry were the = same as that reported by the controller to BSD. What this = boils down to is that such devices may not have partitions = for BSD and non-protected mode OS's simultaneously. It = also means that DOS partitions on the device other than = those which start at the start of the disk will not be = mountable by BSD (or other protected mode OS's) which have = no way to determine the BIOS apparent geometry. = = b) The disks on the secondary controller can not be used to = boot BSD; since the BSD boot blocks are BIOS based, and = the BIOS has no knowledge of the controller, devices on = a controller without BIOS recognition can not be used as = boot devices. = = 2) Not all translation is linear in the BIOS; if the controller is one = which supports bad sector forwarding in BIOS instead of in hardware, = the bad sector forwarding will be disabled. Worse, there will be = a possibility that the layout policy is such that BSD tromps on = the bad sectors forwarded by the BIOS, or vice versa. This type = of sector forwarding should be disabled, if at all possible. = = 3) The conversion from translated (BIOS apparent) to untranslated = (protected mode OS driver apparent) geometry will lose a small = amount of the disk from the "number of cylinders"; this is because = the size will have to be rounded down to a cylinder boundry for = the total number of sectors. Less than one cylinder will be = rendered unusable in this process, but some space will be. = = 4) The bad sector forwarding algorithm in BSD itself locates the bad = sector replacement table at the end of the drive instead of the = beginning; this means that the BIOS boot blocks may be able to = reference forwarded bad sectors from locations written to in = writing the UNIX kernel during linking and/or copying to "/". = This can result in some block in the kernel existing beyond the = DOS 1023 cylinder boundry, rendering it unbootable with the = BIOS boot blocks. The entire BSD disk layout policy needs to = ==END INCLUDED TEXT======================================================== The following is a subsequent posting to a question about drives only indirectly supported by BIOS from DOS -- that is, that don't have a DOS driver to ask geometry from until after DOS has been booted: ==BEGIN INCLUDED TEXT====================================================== = = Actually, I think he has a point; specifically, what if I have: = = o An IDE as primary boot disk, with a DOS partition on it. = o An AHA1742 with BIOS disabled. = o The Adaptec supplemental driver in the IDE DOS partition's = config.sys. = o A DOS partition on a SCSI drive attached to the AHA1742 but = not using the whole disk. = = It turns out that I can't put a BSD partition on the same disk, nor mount = the DOS partition on the disk under BSD without knowing the geometry = imposed by the Adaptec supplemental driver (something I can't know = without loading it -- something I can't do). = = The short, sweet answer is that you can't share drives not known to the = BIOS with protected and non-protected mode OS's. = ==END INCLUDED TEXT======================================================== I view this as an acceptable restriction on disk handling, since, after all, there are going to be some limits imposed by using incredibly cruddy hardware no matter how you try. In a conversation with Bill Jolitz, I suggested that one possible soloution to the drive incompatability problem would be a BIOS-based driver that used a kernel vm86() call to call DOS interupts out of protected mode. The benefit in this should be obvious: any driver recognized by DOS would be recognized by the protected mode OS. The drawback is the same as that for the previously included text, to wit: if the drive is not the primary boot device, it's BIOS access routines (we have already assumed that DOS can recognize the drive) will be loaded only on booting DOS, and the disk will remain unsharable in the protected mode OS. An *unacceptable* workaround would be to boot from DOS. In closing, I would also like to note several things which may not have occured to the majority of the people who might be tempted to go out and implement all this: 1) There are already good people working on this; you could mail them at freebsd-hackers@freefall.cdrom.com and ask them if they could use your assistance instead of trying to reinvent the world. 2) The DOS FS should be updated with concommitant changes at the same time if this is done; there is no reason to reserve any partitions for DOS when the DOS FS could, under this system, simply read and *correctly interpret* the DOS partition table off the raw whole disk without a need for a mount specific driver dev node. 3) All boot blocks written for use in DOS style partitions need to checksum to the correct value. This is why most operating systems besides DOS, OS/2, and SCO can't be booted using the OS/2 boot manager. 4) The changes to do partition handling really, really want to be made in the kernel low level block I/O code for use by all of the filesystem types on a given box; further, they want to be isolated to a single code layer so that Amiga, MAC, SPARC, PPC, and Alpha versions of the FS code *don't* require a DOS partition table to be able to run. Feel free to post corrections as you feel necessary; I'll consider them on their merits and respond. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.