Date: Tue, 18 Mar 1997 11:42:28 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703180112.LAA12765@genesis.atrad.adelaide.edu.au> In-Reply-To: <199703171835.LAA08169@phaeton.artisoft.com> from Terry Lambert at "Mar 17, 97 11:35:00 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > > Q: Why are the users permitted to override geometry? > > > A: Because FreeBSD sometimes gets it wrong. > > > > That's accurate, but incomplete and misleading. FreeBSD sometimes gets it > > wrong because it's not possible to always get it right. > > Bullshit. It is possible to get it right. You may have to rewrite a > scratch area of a disk in order to do it, but it's possible. Windows95 > does it just fine. Ok, so I give you a pathalogical case. I can think of several right off the top of my head; most involve flash memory or read-only media of some sort. Of course, you have no way of knowing that the area of the disk that you've elected to use is actually "scratch", do you? Remember all those nasty comments about MS operating systems eating peoples' disks? > It may be accurate to state that "it's hard for FreeBSD to get it right, > but with slight modifications, FreeBSD could get it right in the vast > majority of cases, and appeal to the user for the rest. I'm sure that > this will come down to machines with identical drives that someone has > duplicated with dd and which have identical defect lists for whatever > reason. An unlikely case. Given unlimited resources and patience, I'm sure you could do that. With the much scantier resources actually available to the bootloader, things aren't so easy. > > > Q: Why does FreeBSD sometimes get it wrong? > > > A: Because FreeBS gets the INT 13 values in the boot loader, but then > > > discards them in favor of the potentially incorrect CMOS and/or > > > non-BIOS drive query return values. > > > > This is not answering the question. > > Yes it is. If FreeBSD did not discard the boot loader values, it would > have the "correct" geometry for the device. The "correctness" of the > geometry is a result of: You are making the (possibly incorrect) assumption that the bootloader has the 'correct' geometry in the first place. This is only valid if the bootloader obtained the correct geometry, and has not been misled or made a mistake. It could do this if it didn't come off the disk in question, or if the BIOS in the system is behaving oddly, or if it was loaded by something other than a vanilla MBR. > 1) Being able to determine the absolute sector offset for a > given C/H/S value in the partition table. This is a basic requirement for reading the second portion of the bootstrap, granted. > If you have read the VFAT32 specification that came on the OEMSR2 > CDROM from Microsoft, you know that the code looks at the partition > data of the disk in order to determine the geometry (just like the > NCR BIOS does in order to make other SCSI controller geometries OK > for the NCR controller). I have little or no time for reading Microsoft's confusing and misleading documentation; I have far too much work creating my own, thanks. Oddly enough, not everybody subscribes to, or _wants_ to subscribe to, MS' developer programs. Personally, I get by quite nicely avoiding subsdising immoral corporates wherever possible, and MS are right up there with Shell and McD's. Reading the partition data on the disk also requires that you are using an MBR in the first place; another poor assumption. > The INT 13 in question is called in the FreeBSD second stage boot block > after switching back to real mode for the call (this is an artifact of > the MACH boot blocks, which could switch back to real mode without > penalty). Check the boot block code if you don't believe me. I am fully aware that the bootblocks have access to the BIOS information. I am also keen to make this information, as well as a lot more, available to the kernel in a useful and disposable format; I just haven't received much in the way of support or time. > > It is not sensible to try to match sector counts against c/h/s values > > from the BIOS in many cases; often the discrepancy can be more than > > one track multiple out. A signature approach might perhaps be better. > > o Multiply the C/H/S geometry of the INT 13 ID's in question by > the C/H/S limit values to get the absolute drive size. Compare > the size against the IDENTIFY size. This will establish disk > identity in the vast majority of cases. Huh? It is almost certain that, in the majority of cases, the C/H/S size will _not_ match the drive's total reported size. You would have to apply a 'nearest fit' heuristic with some intelligence about what is 'near'. Not impossible, no, but not terribly simple. > o Modify the second stage boot to fill in the correct LBA address > in the DOS partition table for a given C/H/S value at boot time; > have BSD *always* use the LBA values in protected mode and > *always* use the C/H/S values in the INT 13 using boot code. > This should cover all other cases except where the drive is > identical. This would be nice. It does, however, require that the second-stage boot be able to write to the disk, which is not always practical (and on many systems will drop the user into a large flashing red "virus alert" screen). > > The correspondence between FreeBSD device and BIOS device is only > > significantly relevant with a mixture of SCSI and IDE devices, or > > multiple SCSI devices on multiple controllers. > > It's relevant when there are two or more devices in the system which > may be identical except for the INT 13 drive ID. The only situation in which it is justifiable to be concerned about which physical drive matches which BIOS drive ID is when attempting to determine from the BIOS disk number of the root device from the bootloader which disk contains the desired root filesystem. In most cases, this is trivial and the whole argument above is moot. However, it is desirable for things to work in _nontrivial_ cases, so we are already talking about border conditions. > > Several of us are playing with three-stage bootcode. If you would be so > > kind as to contribute an ELF loader that understands your segment-colouring > > stuff, preferably as an 'ld.so' for the kernel, we could move to a > > boot-time link approach which could take advantage of this. > > What's wrong with Erich's code to do this? The fact that I have yet to obtain a version of GRUB that can be built on FreeBSD, or that comes with anything approaching the sort of basic functionality I'm looking for? GRUB is a nice idea, but too limited. I would very much like to work with it, but if I can't build it, I can't tinker. In particular, the hardcoded blocklist and "stage 1.5" concepts make me want to puke. It is also salient to note that GRUB has not been updated for over 5 months, making me fairly certain that it's a dead item. My current 'favorite' is the NetBSD libsa, which has all of the bits that I need, modulo perhaps some more network drivers, however it doesn't appear to have all of the "wonderful" ELF stuff that you keep raving about. > > In reality, two versions of the linker will be required; a very stupid > > version that can load the main kernel object and some set of stipulated > > objects for inclusion in the stage-3 bootstrap, and a smarter one that > > should be part of the kernel to replace the current LKM mechanism. > > > > The 'stupid' one would need to fit inside the 64K small-model kernel > > loader module. > > I don't see why the stupid one could not be the same as the smart one, > as long as you were willing to establish PM mappings for it. *shrug* The idea behind having two was simply that the 'stupid' one need only be able to assemble a kernel from a specified list of components, while the 'smart' one needs to run after the kernel has started to add extra components. > As for > segment loading, the most interesting method would be to put modules in > seperate ELF segments in the kernel image itself, jamming them in or > yanking them out at will. The segment coloring is only useful in this > case if your defautl drivers for the console, etc. are colored differently > than the rest of the kernel to allow them to be distinguished (and dumped > at will for replacement). Given this, then a "boot" coloring (see the > Microsoft Developer Network document on the Portable Executable format > for ELF segment coloring) could get loaded leaving the rest for later. It is pointless to make sideways references like this to documents that are effectively inaccessible. If you have a URL, cite it. If the document is not freely available, then either paraphrase enough of it to convey its details, or avoid referencing it as though I should have read it. The connotation is annoying at best, and I find it quite insulting. Look, we're talking about doing something new here. If segment colouring is useful, and I suspect that John could make it so, then there's no reason not to do it. We still need an in-kernel (or attached-to-kernel) ELF linker that can do this. All I'm suggesting is that _I_don't_know_enough_about_it_ to do it, and I am asking that you consider putting some code down that does. > If you read the Schulman book on Win95, this is actually how Windows95 > loads its VXD's and other pieces... only we don't have an IO.SYS that > understands our file system (well, we don't have a publically available > one, anyway). As above, please don't suggest that I have time to lie about in traction reading expensive books that my employer doesn't want on their shelves. On the sort of peanut salary I'm on, a $90.00 book isn't something I'm going to spring for just to read that MS use an in-kernel linker. Big yay. Bruce has already observed that the stage-2 boot can happily read UFS filesystems, so I don't know what your problem is there. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703180112.LAA12765>