Re: VSTa boot

Dave Hudson wrote:
>Bryan Ford wrote:
>>
>> However, supporting both approaches may not be as big of a problem as it
>> may seem at first. The Mach server bootstrap program (the program that
>> loads servers once the "microkernel" has already been started) in the new
>> mach4 distribution already has a rudimentary VFS-like layer and supports
>> MINIX, ext2fs, and BFFS file systems at the same time
>
>Why does mach need the microkernel loaded and running first? Certainly we'd
>have a problem under VSTa as we can't switch back to real mode at the moment
>(and I'm not too sure I'd like to be able to). I know that mach used to
>have it's device drivers running in kernel space - is this still true (and
>thus why we need the microkernel running)?

Basically, it's a brain-damaged side effect of the way Mach developed. :-)
We're working on changing Mach to do things more the way VSTa does -
loading the microkernel and some initial servers all at once right on
bootup; once that transition is completed (and we have a boot loader
that fully supports this method :-) ), we'll get rid of the server
bootstrap program.

>> >BTW I seem to remember something about BSD partitions not being the same as
>> >DOS partitions. If this is true (and I'm not sure) then this also
>> >complicates matters.
>>
>> Maybe even create a "generic
>> partition-interpretation library" or somesuch... :-)
>
>Well we already have code for VSTa to handle dos partitions via a library
>and I guess supporting BSD partitioning wouldn't be a bad idea as well
>(someone's bound to suggest porting BFFS to VSTa sometime).

That sounds good. However, you should still contact the guy who's
working on partition interpretation in Mach (again, another "feature"
of the kernel that really doesn't belong in the kernel :-) ) and coordinate
with him. A generic partition-interpretation library that would work
under multiple OSes and in different environments would be great.
Contact Stephen Williams <steve@icarus.icarus.com>.

>> No, the BSD/Mach boot loaders use the normal BIOS calls. They load
>> large boot images into >1MB memory by switching in and out of protected
>> mode, just like DOS extenders do. In fact, unlike LILO, much of the
>> BSD/Mach boot loader code is written in normal 32-bit C, compiled with GCC.
>
>Does NetBSD do this differently then? I have some of what I believe is the
>standard NetBSD boot code and it talks to the hardware directly.

Hmmm... I've never seen the NetBSD boot code, so you may be right;
I just assumed it worked essentially like the Mach boot code.
I know the Mach boot code uses the "BIOS extender" approach.

>Can you
>point me at BIOS supporting code - thanks :-)

You can get it from kahlua.cs.utah.edu:/pub/mach/mach4-i386-UK02p6.tar.gz,
in the directory mach4-i386/kernel/i386at/boot in the tar file.
(Or if you'd prefer not to download the whole 300K source tree
just to get the boot code, tell me and I'll create a smaller archive.)

BTW, the Mach boot code uses a sort of kludgy way of coaxing 16-bit
assembly language code out of gas, rather than using some other assembler
such as as86. This has the advantage that it can be easily cross-compiled,
but of course the 16-bit code is rather ugly. It seems like it should be
almost trivial to change gas to support 16-bit code - basically just a
matter of adding a directive that inverts the decision of whether or not
to add a size prefix to each instruction, right? It might be worth looking
into this before writing lots of new 16-bit code with either of the
less-than-adequate existing methods.

>> Oops, I see you already had the basic idea - so I guess my news is that
>> it's already done, and the code is available. :-)
>
>I'd like to see what's been done before, but I'm beginning to suspect that
>we need something new (just borrowing functions from elsewhere).

I agree - it's no simple addition to one of the existing boot loaders -
it's more a matter of gluing together a bunch of scattered existing routines
into an entirely new boot loader.

Thanks, and good luck! :-)

                                Bryan
Received on Sun Nov 6 08:00:40 1994