Date: Tue, 18 Nov 1997 03:23:53 -0800 From: Jonathan Mini <j_mini@efn.org> To: Tony Overfield <tony@dell.com> Cc: Jonathan Mini <j_mini@efn.org>, hackers@freebsd.org Subject: Re: >64MB Message-ID: <19971118032353.57770@micron.mini.net> In-Reply-To: <3.0.3.32.19971118043736.006d7d48@bugs.us.dell.com>; from Tony Overfield on Tue, Nov 18, 1997 at 04:37:36AM -0600 References: <3.0.3.32.19971118043736.006d7d48@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Overfield <tony@dell.com> stands accused of saying:
> At 02:58 AM 11/10/97 -0800, Jonathan Mini wrote:
> > 1) The boot blocks are a part of the boot process, meaning that
> > they should function in real mode (being part of initializing the
> > processor) and the sole function of this code is to load the kernel
> > into memory. (this is bogus, IMO)
>
> Well, I don't think it's bogus, and Terry seems to want this one, if I
> haven't mistaken his statements. This has certain ideological advantages
> with respect to portability and multiple platform development.
Hmm. As I read his reply, he seemed to be a proponent of setting up a vm86
TSS for the real mode code.
> > 2) The boot blocks are a small microkernel who's sole purpose is to
> > load the main kernel (or possible a second micro-kernel which handles
> > config : read three stage boot) into memory and give it control. To
> > do this, it needs to have two contexts :
> > a) a protected context with mappings for the kernel, and
> > b) a vm86 context for talking to the BIOS.
>
> Yes, this is one possible approach, but I still think it offers no extra
> value over what we have now. Please don't assume I don't understand these
> issues. Regardless, I don't really care what approach is taken, so long
> as it is implemented correctly. Also remember that I'm referring to boot
> time code only.
I understand, but your second statement eludes me. You say that you don't
care what approach is taken, as long as the code is implementd properly? But
the approach taken to the solution is half of the implementation. A hack is
still a hack, even if it is the most beutiful code within itself.
> > The boot blocks shouldn't be constantly hopping from Real Mode to Protected
> >Mode over and over again! This is insane,
>
> No, this is done all the time. Switching between modes is fast, small and
> easy (excluding the '286, of course).
Whether or not something is 'done all the time' is not an issue, it is still
insane.
> [ ... snip ... ]
> I'm quite familiar with the various things in a BIOS that can break
> Windows 95, DOS, QEMM, EMM386, etc. Real mode has PE=0, so code that
> wants to hijack the processor state can know that "ring 0 run state"
> is irrelevant. I did say that I knew of no BIOS that does this, but
> it is possible, without breaking any of the programs you mentioned,
> except for, possibly, the "big limits" code which started all of this.
Then you should know that Win 95, QEMM, EMM386, and OS/2 (to name a few)
run the processor in a vm86 task the whole time, to maintain their virtual
memory mappings. (and EMS emulation) -- even when calling the BIOS.
> Fortunately, there's nothing to be gained by adding "big limits" code
> into a bootloader, so that whole discussion is tangential, unnecessary,
> and uninteresting.
In essence, you are right. This discussion is besides the point, and boring.
Whether or not anything would be gained was the topic of debate, so I have
to disagree. I would come up with convincing evidence, but I prefer to drop
this debate.
> BTW, I assume the "spec" that you speak of is the defacto (and
> imaginary) "must run all code without bugs" spec that I am forced
> to use (among the many others that do exist). ;-)
Yes and no. THe 'spec' I speak of is from several specifications, which
all boil down to the fact that once the BIOS gives the processor to the
OS, it doesn't get to play hanky-panky with the machine state.
> [ ... snip ... ]
> >> I simply don't believe 1) that the booloader does enough of these to
> >> matter, and 2) that anyone really cares about the performance of code
> >> that runs for less than one second per boot (on my systems, at least).
> >> On every system I've seen, the bootloader spends most of that second
> >> either waiting for I/O, or doing I/O.
> >
> > The point isn't really performance, but rather that we should be running in
> >protected mode ASAP. Especially since we don't have a 16bit compiler.
>
> But it already goes into protected mode ASAP. A 16-bit compiler is not
> needed, though the code could be a little smaller if we had one.
Ahh, but we do :
/pub/FreeBSD/FreeBSD-current/ports/devel/bcc
It's not that great, but it does work.
> >> > There are four reasons :
> >>
> >> [Four good, irrelevant, and deleted reasons...]
> >
> > These reasons _AREN'T_ irrelevent, simply because they are the major
> >reasons for having a PROTECTED mode in the first place. Which makes those
> >reasons solely good and deleted. Yay.
>
> All four points are good, as I noted, but they just don't apply.
>
> Reason 1 is irrelevant because there's no VM in the bootloader.
> Reason 2 is irrelevant because the bootloader doesn't take over the
> hardware IRQ's from the BIOS.
> Reason 3 is irrelevant because the bootloader doesn't make, or need to
> make, multiple concurrent BIOS calls.
> Reason 4 is irrelevant because the claim that the BIOS is untrustworthy
> during boot time is ridiculous and not even worthy of debate, IMHO.
I must have made that statement back when I thought that we were still
talking about after-the-kernel-has-taken-control-of-the-system stage of
boot, or later, such as while running the scheduler.
> > THe VM86 facility you are talking about will ONLY exist after the kernel
> >has 'taken over' the machine's state.
>
> So here you finally agree with me? Like I said, don't use vm86() mode until
> the kernel takes over. Use real mode and protected mode, as appropriate,
> until the kernel takes over.
Why do you keep putting paren's around vm86? Are you referring to the VM86()
functionality that Mike Smith is working on, or are you referring to a TSS
with the vm86 adressing model?
> [ ... much argument which arose from you and I thinking of different stages
> of the boot provess deleted ... ]
--
Jonathan Mini Ingenious Productions
Software Development P.O. Box 5693,
Eugene, Or. 97405
"A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971118032353.57770>