Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.development Subject: Re: FreeBSD 2.0: someone please fix mount_pcfs Date: 20 Aug 1994 19:42:16 GMT Organization: Weber State University, Ogden, UT Lines: 48 Message-ID: <335mao$20r@u.cc.utah.edu> References: <32uvui$dov@Venus.mcs.com> <331b5v$q00@u.cc.utah.edu> <331v11$kjs@news.u.washington.edu> NNTP-Posting-Host: cs.weber.edu In article <331v11$kjs@news.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes: ] >The reasoning is that the DOS partition table, which you would have ] >to read to do the mount, barring a partition with a disklabel (or ] >in the UnixWare case, a Volume Table Of Contents), there is no way ] >to decode the C/H/S values as absolute sector offsets without a ] >firm grasp of the BIOS apparent geometry on a translated (ie: modern) ] >disk drive. I suspect SCO will fail this test on modern drives. ] ] I'm not sure I understand the problem. Why can't the OS figure out the ] geometry by reading the partition map? MS-DOS partitions end on cylinder ] boundaries, and so by looking at the partition map entry for DOS the ] dos partition, you can figure out the number of sectors and heads ] that the BIOS reported to DOS when DOS fdisk created the DOS partition. Because this presumes that the C/H/S values are non-commutative, which would not be the case in 1 out of 4 circumsatnces where there are two partitions on the disk and the translated geometry values for H and S offsets for both partitions had two or more common multiplicative factors. If that were the case, you would not be able to determine if the factor belonged to the C or to the H. Since the second partition is not an MS-DOS partition, and therefore does not have the restriction of ending on a cylinder boundry, you are screwed. The cannonically correct soloution is to ask the BIOS itself for the BIOS apparent drive geometry in the second stage boot, which runs under BIOS if it's written correctly. This is either done by making a call to INT 13 AH=8, AL=0x80/0x81 for the BIOS recognized drives, or by looking at bit 7 of EBDA:EC, and if set, looking in EBDA:3D through EBDA:4C for hard disk 0, and EBDA:4D through EBDA:5C for hard disk 1. Then the boot passes this information on to the kernel. Or, alternately, you allow the use of a VM86 call to make the INT 13, AH=8 calls from protected mode. Of course, you are still screwed if your device is "stacked" or if it uses a non-linear geometry translation (ie: inteleaves replacement sectors in BIOS to imitate a "zero defect" drive), etc. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.