Re: VSTa boot

>I've done quite a lot of work on this sort of code over the last year
>(including the rework of bfs and some code that's not hit the standard
>distribution as it's waiting for some extensions to libc to be included) and
>I've got a couple of comments and ideas:
>
>As well as the free OS code we'd also need to support booting DOS, OS/2 and
>NT (it's not going away for a while I suspect). Several people I've
>mentioned OS's like Linux and VSTa to all say the same thing - how easy is
>it to get this to work with my existing system/OS? A major reason for being
>able to use VSTa for code at work is because I can install it to boot from
>DOS via the DOS 6.22 config manager.

I agree that booting DOS, OS/2, NT, and other OS's will definitely be needed,
but it can probably be handled just like LILO does it: chain to another boot
block loaded from a particular partition.

>That said, I like the multi-boot idea but after some experience of this now
>and having worked with a couple of fs's here are a couple of problems I
>think we'd need to overcome (and some possible solutions):
>
>1) FS independence
>
>This is a difficult one - adding the ability to read all fs's we need is one
>possibility (simpler than a general case though as there's no need to check
>permissions, handle writes, handle concurrency, etc). Another solution is
>to provide tools for, or facilities within, each fs to be able to create a
>map of physical media blocks for any particular file. This whole issue can
>be complicated by the fact that I can layer one fs on top of another (eg to
>provide VSTa permissions and long filenames on top of a DOS FAT fs).

Both the FS-interpretation approach and the FS-independent block list
approach have their advantages and disadvantages, and for a boot loader to
be useable on all three major free OS's (Linux, BSD, VSTa) it would probably
have to support both methods. For one thing, I'm pretty sure it takes
special system calls (or in the case of VSTa and Mach, special FS server RPCs)
to calculate block lists for embedding in the boot loader, and It's likely
that BSD doesn't have such calls since they've always had just one "main"
type of file system and have always gone with the FS interpretation
approach. So if you're installing the boot loader under BSD, you probably
can't calculate block lists at all. (Somebody tell me if I'm wrong.)
On the other hand, block lists are the _only_ way to support arbitrary
file systems that the boot loader doesn't directly know about.

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 (it automatically
determines filesystem type and uses the appropriate interpretation code).
You could take this code and add a fourth "file system type", which would
really be more like a pseudo-filesystem that reads data based on
precalculated LILO-style block lists. That way you'd get the benefits of
both approaches: the boot loader would support certain common filesystems
directly, and any other filesystem indirectly with the block list approach.

>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.

That's true, and it is indeed a problem, but not a really big one.
Basically the boot loader just needs to be able to detect and interpret
more than one partitioning format, and nested partitions, in addition to
multiple file system formats. (BSD systems are typically set up with a
disk partitioned into DOS partitioned, with one of those DOS partitions
sub-partitioned BSD-style. Ugly, but that's the way it is...) Someone's
already working on bashing the Mach partition-interpretation code into
something semi-encapsulated and environment-independent; if you want I can
put you in contact with him and you two can work out how to set things up
so both Mach and your boot loader (and potentially other clients) can use
the same partition interpretation code. Maybe even create a "generic
partition-interpretation library" or somesuch... :-)

>FWIW I believe these are the fs's we'd have to support to cover most of the
>free OS set (there are more): minix, ext2fs, bffs, vstafs, dos fat, and
>umsdos.

This looks like a good list, although umsdos is not absolutely necessary
since files written through umsdos can be accessed by the same names
through a traditional msdos filesystem as long as they're not too long or
have funny characters or anything. And as I said before, the first three
are already covered. :-)

>2) Pre-boot I/O
>
>In order to support a loader that can read multiple modules we need to
>provide a way to interact with the loader. There are two ways to do this -
>through the BIOS or via our own device drivers. If we say we'll write our
>own cut-down drivers (we don't need writes to disks say) then it means
>coding a driver for all of our possible BIOS supported boot devices, our
>keyboard, screens, RS-232 and I'd guess ethernet, etc.

I think this would be a really bad idea...

>I believe this is
>how BSD does things but I really don't like it - I can envisage a boot
>loader that's bigger than our OS :-(

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.
(LILO is written all in 16-bit assembly language - hardly an ideal
situation. :-) ) You could basically just pick up the BSD boot loader,
which already handles the basic mode switching and disk loading, and start
adding in the additional functionality to handle multiple boot modules,
different file systems, etc.

>The alternative is to use BIOS calls
>and thus real mode which is where we get our 512k limits from (we'll use
>128k for vector tables, data areas and loader code). I've always planned to
>use the BIOS facilities for this (like Linux) which is why I ported bin86.
>What we could do to get round the 512k limit is write a mini BIOS-extender
>(same idea as a DOS-extender) that provides us with a mechanism to bounce
>data into extended memory as well as base memory. This will take a bit of
>coding, but as performance isn't the issue we can just switch between real
>and protected mode (avoiding V86 mode) - the DOS Oberon system used to do
>this (I don't know if it still does). At least with a BIOS-extender we can
>write some of our code with GCC :-) (although not using our standard libc)

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. :-)

Good luck!
                                Bryan
Received on Sat Nov 5 17:02:09 1994