Date: Wed, 19 Mar 1997 11:19:47 +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: <199703190049.LAA20233@genesis.atrad.adelaide.edu.au> In-Reply-To: <199703181834.LAA09912@phaeton.artisoft.com> from Terry Lambert at "Mar 18, 97 11:34:23 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > 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. There are? We haven't yet established where "the front of the disk" is yet. It's not safe (or reliable) to try to rewrite the MBR (virus protection), or the slack space following (some other systems put bootstraps there). Then the next cylinder might be a partition. > > 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-). No, I said the practicalities are horrific. I don't see an int13 driver giving us anything that we don't have already. > > 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. DOS can be booted from lots of places; think "network boot", or "floppy disk". So can FreeBSD; there is no guarantee there at all. > 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. That's one case. > 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). Yes. Fortunately, the need for DiskMangler is fading fast. > 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. Reading the documentation implies access to it. My point is that access to the documentation you are suggesting comes at a price that I cannot stomach. So far, I've done remarkably well with a copy of the old Pink Shirt Book. > Well, yes, I've been raving for ELF. With John Polstra's "branding" > patches, the last real techinical issue against it is gone. Apparently ILT has made changes to the FSF tools for some sort of ABI branding; I am hopeful that this will be adequate and, preferably, compatible 8) > 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. The initial loader pass should include the kernel core and whatever boot-critical devices are required. This obviates the need for any devices at all in the kernel core. I realise that this is going to take some serious work; I'd love to have the time to do this properly 8( > 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. This is actually a huge issue; the assumption that devices are numbered from 0->(NFOO-1) is another wart that I would like to rip. > 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. Ok; still, I'm happy to hear that _something_ is being done about it. > > > 0x40000000 Readable section > > > 0x80000000 Writable section > > ?! > > Think of "-fwriteable_strings"... There are 4 possible combinations of those values : 0) not readable, not writable 1) readable, not writable 2) not readable, writable 3) readable, writable Of those, remembering that this is a program's text file, I can only see 1) and 3) being any use, ie. the 'readable' bit is pointless. > 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. Hmm. The nature of the boot-time linking process would probably imply that all of the objects in question would have to be loaded, as there would be no paging mechanism by which unloaded sections could be loaded until after the system was up, and possibly not even then (eg. boot from network server, no kernel core locally). > > Public libraries tend not to have technical books. > > Whoah. No wonder you guys are so gung-ho on the Internet... Yeah. And don't get me started on getting technical literature out of hardware vendors. You have any details on the "Apollo Utility chip" in the HP9000/4xx machines? 8) > 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?199703190049.LAA20233>