Date: Tue, 18 Mar 1997 11:34:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703181834.LAA09912@phaeton.artisoft.com> In-Reply-To: <199703180323.NAA14257@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 18, 97 01:53:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703181834.LAA09912>