From owner-freebsd-hackers Tue Mar 18 10:46:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17090 for hackers-outgoing; Tue, 18 Mar 1997 10:46:22 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17080 for ; Tue, 18 Mar 1997 10:46:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA09912; Tue, 18 Mar 1997 11:34:23 -0700 From: Terry Lambert Message-Id: <199703181834.LAA09912@phaeton.artisoft.com> Subject: Re: wd driver questions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 18 Mar 1997 11:34:23 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703180323.NAA14257@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 18, 97 01:53:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Given that we have established that it's not feasible or desirable to > write to the media, as it's not possible to determine where is a safe > place on said media to write to until after we have obtained the facts > that we are trying to obtain, this doesn't work. We've established no such ting. For an invalid partition, or for equivalent partition IDs which differ only in value, there are a number of things it is quite safe to twiddle with at the front of the disk. > Also, the practicalities involved in the int13 driver you're discussing > are horrific. You said impossible. Now you say impractical. How soon until we get to unavoidable? 8-). > I'm not shamed by your reference; I just can't see the relevance. The reference was intended to point out another example of a protected mode OS that can interoperate reliably with the DOS boot process, since I didn't seem to be getting anywhere with NT and Win95 examples. It was not intended to shame you, it was intended to refute the "too hard for anyone by MS" argument. > > Hopefully by "unlimited resources" you were referring to MS? > > No, I'm referring to the dearth of _space_ in the second-stage bootstrap. You have said you are already puttering with a 3 stage boot. Space is an obfuscation, not an issue. > > If the bootloader was misled, DOS was identically mislead, and since > > all we really care about here is interoperability with DOS installed > > on the same drive (or another OS that must also care about interoperability > > with DOS installed on the same drive), it is *correct* to allow ourselves > > to be "misled". > > What we care about is finding sectors on the disk, given some information > in c/h/s format. It is only correct that we are similarly misled to DOS if > we were booted from the same source as DOS. This is not necessarily so. ??? DOS can only boot off the initial drive. FreeBSD will only boot off the initial drive after install. The only issue you can be referring to is the OnTrack boot manager on the hard drive during a boot-from-floppy install, where the OnTrack code will not modify the values returned by the INT 13. This can be reconciled by using LBA based I/O, if possible, and by recognizing the OnTrack code, if not (recognition of the OnTrack code is already implemented). > I am not complaining about examining any particular OS. I am > complaining about your suggestion that I should be subscribed to a > developer indoctrination service for an organisation and environment > that I find personally anathematical. If said organisation or said > interoperability plaintiffs were to provide useful and relevant > documentation on the topic of interoperability, I would be happy to > study it. Well, I said to read the documentation, not to buy it. Am I a plaintiff by this description? Tell me what you want, and I will try to provide the information in paraphrased for other form that won't violate my license. As far as boot goes, I'd *really* suggest you download the PReP specification from the IBM, Apple, or Motorolla WWW site; chapter 5 has perhaps the most extensive discussion of the DOS partition table that I have seen in recent years. > Supporting an MBR is good. Mandating one is not the current Way Of Things. Change "the current Way Of Things"; it has no special position in the order of the universe, other than its ruts fill with mud faster when it rains. > It is valid to suggest that we should mandate the use of an MBR and > corresponding partition information, but you will encounter users that > will Not Like This. Oh well. I'll feel bad for a nanosecond, and then shrug it off, knowing that it is more important to run on as much hardware as possible than it is to assuage the MBR bigotry of a few people who don't care if we can run on everyone's hardware, so long as we already run on theirs ("I got mine; screw you if you want yours" is a bad attitude, one which I will not tacitly condone). > > Size-ordered BSD device list, bsearch for BIOS sizes. *Very* simple. > > Not so simple. Introduce a set of devices that are found by the > BIOS but not by BSD, and vice versa. Sort amusingly. Again, remeber > that we are only looking for one device to match the sizing of a > single BIOS disk. That device will have a DOS partition table with a BSD 0xA5 in it, an it will have a boot block and disklabel at the offset of the right geometry times the 0xA5 partitions C/H/S value. The more interesting case is foreign FS's mounted from drives without a BSD 0xA5 partition; there are still hueristics which you can apply thre. For instance, remove the boot device from the contention after you've found it. 8-). > A great many machines support int13 "virus alert" services. It isn't > an issue at the point where we are writing a partition table as by then > we are in protected mode talking directly to the disk. > > It's not a major issue, but it has the potential to be a support wart. Less of a support wart than "can not mount root", and "can not mount corrupt MSDOSFS, please fsck", I suspect. > > I've never raved about ELF in NetBSD... not even in their boot code. > > No, I am referring to the "segment colouring" and other things that you > appear (justifiably?) to feel are worthwhile using ELF for. I am still > studying the libsa code, so I could well have missed a lot. Well, yes, I've been raving for ELF. With John Polstra's "branding" patches, the last real techinical issue against it is gone. > > Actually, you want to be able to load all segments with a certain set > > of tag bits from the kernel image file, which is a single ELF file. > > MHO is that the kernel should _not_ be a monolithic file, but rather > the 'core' kernel and a collection of linkable objects (drivers, > optional extras, etc.) > > This would allow constructing seperate kernels from a single repository > of objects, etc. I would prefer this as well. But if you wanted to support only one file in the vn_* routines in real mode, and then support multiple files after word, then you could make the kernel contain all boot-critical devices. You should probably do this anyway. As far as it not being monolithic: it's probably desirable to be able to "config" devices into and out of the default image by adding or removing segments from the monolithic ELF binary. At the very least, it means no recompilation to support config options, as long as we get rid of the static compilation issues in shared code (#if FEATURE > 1) and so on. > > The lack of a coherent kernel level vnode-as-descriptor based file > > I/O subsystem is one of the things that is wrong in the FreeBSD kernel. > > The vn_* routines are seriously incoherent compared to, for instance, > > the AIX kernel file I/O interface. > > The solution to this is well known; I am hoping that you have provided > your changes to Julian and/or phk so that I can then pursue them with > regard to having them integrated. The initial set of changes, divorced from the rest of them, were provided to Julian before the Lite2 integration started. He still has them. Because I have to provide changes in "bite sized chunks" to allow them to be digested, we will have to incrementally work back up to where I was on my own machines in June of 1994. A coherent kernel file I/O interface is about three chunks past the currently outstanding chunk. > > http://www.microsoft.com/win32dev/base/pefile.htm > > Thanks for the reference. Unfortunately, this document makes no > mention of "colouring" (in either spelling) boot or otherwise. It > describes PE as a mutant form of COFF, which I already knew. > > At best, I presume you are referring to the 'section characteristics' > attribute. Yes. I refer to it as "coloring" because that is the proper term for atributing page ranges (a section is a page range) by VM characteristics. > > 0x40000000 Readable section > > 0x80000000 Writable section > ?! Think of "-fwriteable_strings"... > The point, however, is that these attributes are not useful until the > VM system is up and running. The initial linker pass has to run > _before_ this; still, it shouldn't be hard to walk the attributes at > a later stage to pass them on. Yes. The utility of the attributes at boot time is to decide to load a particular segment or not. Preload is the most interesting attribute in this regard; it should probably be implied on non-pageable segments. > You could, at least, have renumbered the bits rather than use the > same (nonsensical) assignments that MS did 8) I could have, but it would have been "TerryPE" instead of "PE". 8-). [ ...Technical library?... ] > The short answer is : No, we don't. The longer answer is : > (technical) Books cost a small fortune in this country for some > inexplicable reason. eg. Stevens UNP, a fairly stock programmer's > staple, lists at AUD$90 (about US$70). Ordering non-stock books can > often add 10-15% to that. > > Public libraries tend not to have technical books. Whoah. No wonder you guys are so gung-ho on the Internet... Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.