Re: Booting VSTa

Andrew Valencia writes:
 ..
> It's hard for me to comment, since I think we need to spell out a couple
> implicit assumptions:
>
> 1. We want to choose operating systems from a boot prompt
> 2. Once we choose one, we want to enter that OS with no intermediate
> steps.
> 3. We don't mind requiring a DOS partition (or do we?).
> 4. If all the self-hosted compiles are under a vstafs partition, we
> don't mind copying them to a DOS partition (I would mind, or
> rather, I would add a "make install" build step).
> 5. We don't mind if our boots fail in mysterious ways because a server
> got re-built (but the sector map wasn't updated).
> 6. We want to be able to boot on machines with no DOS.
 ..
> A LILO-like loader which understands DOS filesystems satisfies 1, 2,
> 3, 5. It fails on 6. But if we teach it vstafs, it could cover 6,

False. LILO gets the physical sectors from the OS when you install a
new image. The boot-part of LILO has no filesystem knowledge. This is
one of the (good) design decisions, as LILO will work no matter which
kind of filesystem the future might bring. (As long as files remain in
place, unlike Log Structured Filessystems.)

I'd suggest either porting LILO to VSTa (fairly easy?) or using
a similar scheme.

Dave Hudson writes:
> Ok, I've had a bit more time to think about the boot problem and I have a
> new idea I'd like to bounce around.
>
> There's one prerequisite to all of this thinking - I believe that I'm right
> in thinking that it should be possible to create a filesystem within a file
> of another filesystem (a bit like stacker does under DOS). If I've got this
> wrong stop me now :-)
>
> I still like the idea of keeping the flexibility in having a "boot.lst"
> file, but I don't want to force boot filesystems onto people who have no
> need for them (or in the case of floppy booting people who really can't have
> 2 partitions). What I was thinking is this:
>
>
> 1. Invent a new boot file system type - very simple, with limited if any
> subdirectory handling.

I could suggest "tar".

> 2. Create utilities to make and repair the boot file system, where the fs
> can be made on a raw disk partition or a largish file of an existing fs.
>
> 3. Write a boot filesystem server.
>
> 4. Write a LILO like boot manager, but instead of reading command parameters
> and writing them into a data area or bootsector (as under Linux), write them
> into the area reserved for command line parameters of the boot time servers.
>
> 5. Ensure that any shutdown utility checks that if our boot fs is really a
> file of another fs, that some defined action can be taken in the event that
> the boot fs file has been moved.
>
>
> So far I can't see any obvious problems. As I see it:
>
> A. The new fs behaves like any other fs, eg mount it as "/boot" and we have
> something like:
>
> /boot/vsta
> /boot/dos
> /boot/rs232
> /boot/rs232.new.100193
>
> B. We can have different versions/implementations of the same server (eg the
> 2 rs232 drivers in the example above) without having to have 2 complete boot
> time images.
>
> C. The only thing we need to be able to do is determine where all of the
> sectors of the boot fs are, irrespective of whether it's a partition in its
> own right or whether it's a file in another fs.
>
>
> So, (quickly dons a flame proof suit) are there any glaringly obvious points
> I've missed here? I'd like to hear any comments. If there's support for
> this way forward, how many files would such a boot fs need to support (as a
> default - the mkfs facility should allow fewer/more to be selected). Also
> how many characters should the filenames be (max). I was thinking about
> 24-30ish.

Please explain to me why this would be much better, than just running
something lilo-like when you would otherwise had reorganized the files
in your bootfs?

/Tommy
Received on Mon Jan 10 09:49:18 1994