Re: boot floppy

> [David Eagle <DEAGLE@postoff1.promus.com> writes:]
>
> > How do I create a boot diskette? Is this even possible? If not,
> >when do we expect such a capability to be ready? In particular, I would
like to boot
> >off a 1.4M floppy.

>There are two possibilities at the moment for boot floppy support - one is
>to put a dos fs on it and boot normally, but even with my patched code for
>boot.exe and fd this took me about a minute to boot (demand paging from
>floppy is painful). The other is to create a boot floppy image and load it
>all in one go, but this means having things statically linked as boot
>servers.

So let me see if I understand. There IS a way to create a VSTa boot
diskette.
But you have to link in a special way. Is there a utility that then creates
the
boot diskette? Is that utility in the "complete" copy of VSTa that Andy
sent
me? Is there documentation on how to perform this special link?

> I've been looking at some improvements though - one is to improve the
>capabilities of the fd server (to implement much better caching
strategies),
>and the other is implement a variant on the Linux xiafs boot mechanism (if
>anyone remembers this :-)). The idea would be to make the boot servers and
>kernel load from a single image (pretty easy) and then have one of them
load
>the remainder of the diskette as a compressed boot fs image (xiafs of
course
>did this without compression for booting hard-drives so it couldn't move
the
>fs image about, but we can here).

Hmmm... I don't see how improving the fd server could possibly help speed up
the boot process. The fd server can't run until the OS is loaded and
running!
Also, why would the boot server and kernel have to be bound as a single
object?
In fact, why are we even talking about a "boot server"? Isn't the word
"server"
meant to refer to an application running under VSTa? Shouldn't we be
talking
about a "bootstrap loader"? I envisioned a very simple (1 or 2 K) loader
that
is loaded by my computer's ROM, which then has the job of loading and
starting
the OS.

I envisioned the boot process unfolding thusly:

   1. Power on computer. ROM takes over.

elapsed time: nanoseconds

   2. ROM finds valid boot sector on floppy disk. ROM loads and jumps to
boot
        sector.

elapsed time: tenths of seconds (assume CMOS controlled memory/integrity
                                                                checks are
disabled)

  3. Our bootstrap loader takes over. He reads and decompresses into
memory
        as much of the OS as we care to bind together. Let's imagine for a
moment
        that this is a minimal kernel.

elapsed time: tenths of seconds

  4. The minimal kernel takes over. The first thing it does is IMMEDIATELY
present
        a logon interface. Then, as a background process, it continues
reading,
        decompressing, and kicking off servers, device drivers, system
integrity checks,
        etc. etc. etc.

elapsed time: maybe a full second passes between flipping the power on
and
                             seeing the logon screen.

  5. The user can log in as soon as s/he wants. Some operations may be
slow if the
        needed driver/server has not yet finished loading.

  6. Once initialization is complete, all the kernel initialization code is
kicked out of
        memory to free up more space for applications.

>> >What would be really cool is if I could boot from a floppy on a
floppy-only
>> >system with about 8M memory, decompress the entire floppy into memory,
and
>> >(after allowing 3M for the expanded boot diskette and 1M for system data

>> >areas) have about 4M for user program space.
>>
>> Sounds quite reasonable. You might want to enhance srv/tmpfs to permit
>> subdirectories. Or, you could run a filesystem on top of GNU zip on top
of
>> the compressed data (but then you have to leave the floppy in the drive).

>Something like tcx might work too. Of course another highly desireable
>feature for this would be some sort of execute-in-place facility for
>memory-mapped filesystems (I'm not sure if tmpfs does this or not). It's
>something I'd like to get working for use with some memory mapped flash
>filesystems. Basically just map the code directly, and use the data
>copy-on-write.

Gosh, I hope I understand this last issue once I get deeper into VSTa.
Received on Thu May 4 07:00:01 1995