From owner-freebsd-hackers Mon Mar 17 19:25:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27297 for hackers-outgoing; Mon, 17 Mar 1997 19:25:10 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA27290 for ; Mon, 17 Mar 1997 19:25:05 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA14257; Tue, 18 Mar 1997 13:53:47 +1030 (CST) From: Michael Smith Message-Id: <199703180323.NAA14257@genesis.atrad.adelaide.edu.au> Subject: Re: wd driver questions In-Reply-To: <199703180225.TAA08818@phaeton.artisoft.com> from Terry Lambert at "Mar 17, 97 07:25:36 pm" To: terry@lambert.org (Terry Lambert) Date: Tue, 18 Mar 1997 13:53:47 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De X-Mailer: ELM [version 2.4ME+ PL28 (25)] 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 Terry Lambert stands accused of saying: > > 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? > > The "cannonically correct" way to do this is to get the protected mode > driver up in parallel with a VM86()-based INT-13 using driver, and if you > can't tell two media apart, write on one of them with one driver and > notice the change with the other. 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. Also, the practicalities involved in the int13 driver you're discussing are horrific. > > 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. > > Linux does it. Isn't FreeBSD as good as Linux? Which particular > resource do they have that FreeBSD doesn't? I feel low trotting out > the old "Linux" card, but you leave me little choice in this dialectic. Linux does things somewhat differently. I don't like their approach a great deal, from what little I've studied it. Perhaps their way works for them; I'm seeking a way that works for me/us. I'm not shamed by your reference; I just can't see the relevance. > Hopefully by "unlimited resources" you were referring to MS? No, I'm referring to the dearth of _space_ in the second-stage bootstrap. > 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. > The problems with the boot are MS OS boot interoperability problems, > nothing more. If you have an issue about dealing with interoperability > problems by examining the software with which you are attempting to > interoperate, well, all I can say is that you are unlikely to ever > solve your problem. 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. > > Reading the partition data on the disk also requires that you are using > > an MBR in the first place; another poor assumption. > > No, it's not. You should *always* have an MBR (or whatever passes for > a native MBR on non-x86 computers -- on PPC's which comply with either > PReP or CHRP, it's a DOS MBR. On DEC Alpha's, it's a DOS MBR). This > is common sense, since it reduces the number of cases you must consider > when you are trying to recognize the thing. Supporting an MBR is good. Mandating one is not the current Way Of Things. 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. > > > 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. > > 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. > Only write it if the values are wrong. After you write it once, they > aren't wrong. In the "Virus alert" case (few machines offer this at > the INT 13 level anyway), instruct the user to override. We must > already be instructing the user to do this to install our partition > table entry anyway, right? One partition table write can not be > distinguished from another. A write of that disk address range is a > write of that disk address range. 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. > > 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. > > 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. > 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. > 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. > 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. > Segment coloring refers to attribute bits for VM handling based on > which ELF segment the page in question came from: > > 0x00000020 Code section text > 0x00000040 Initialized data section data > 0x00000080 Uninitialized data section bss > 0x04000000 Section cannot be cached I want to modify this and not care about the CPU > 0x08000000 Section is not pageable I might have an interrupt handler in here > 0x10000000 Section is shared I might use this for IPC > 0x20000000 Executable section text > 0x40000000 Readable section > 0x80000000 Writable section ?! 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. You could, at least, have renumbered the bits rather than use the same (nonsensical) assignments that MS did 8) > There is sample code available for download at the URL above. If you > need more, I've duplicated this effort to be able to load symbol > tables from Microsoft Debug format and from SoftICE files into a > non-statistical profiler for VXD's, when porting the Heidemann > framework to Windows95, so I suppose I could give you some similar > samples, though my header file for the reverse engineer was not > nearly as complete as the ones on the URL above. I couldn't care less about reading PE files. My primary concern is the communication of the attribute information to the VM system, and secondarily the parsing of ELF format files. > The problem is in conversion from real-mode (INT-13/INT-21 based) disk > drivers over to protected mode disk drivers. I was simply giving an > example of how it had been done. Don't you have a technical library > in your corner of the world? 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. > The main point is that the real mode code and the protected mode code > for the VXD (PE format image) loader are the same, so there's precedent > that it's possible to implement without a "smart" vs. "stupid" loader > dichotomy. TBH, I don't think this has any relevancy at all. We are talking about environments that, rose-coloured glasses or no, are really quite different. > 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 [[