Re: VSTa boot

Hi,

> It sounds like what you're planning to do at this point is essentially
> rewrite LILO to support multiple boot modules and to run under VSTa.
> With a little planning, I think you could fairly easily create a boot loader
> that supports VSTa, Linux, Mach, and BSD at the same time in basically the
> same way, and could easily become "the definitive free OS boot loader". :-)
> There's also a lot of already-written free boot loader code I could point
> you to that might make your job easier.

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.

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

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.

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.

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

I think we can get to a stage where we can boot VSTa without DOS easily and
perhaps we can show the way on how to tackle the problem to other OS's, but
I think we'll find it difficult to create a *definitive* boot loader.

                        Regards,
                        Dave
Received on Sat Nov 5 16:11:52 1994