>From port-alpha-owner-mjacob=feral.com@NetBSD.ORG Wed Dec 18 06:30:06 1996
>
>> MILO is less than attractive because it really overengineers
>> the relatively simple problem of trying to boot off of disks.
>> My big beef with MILO (which I used for about 4 months) was
>> you couldn't exit back to the SRM. It doesn't know how to
>> read FFS filesystems, but could be taught to do so trivially.
>
>Actually, i think i was being stupid when i suggested that it should.
>
>I _really_ don't like the idea of firmware (which is what MILO is)
>understanding the file system type.  I'd rather just have it load a
>file from certain disk sectors, like SRM console does, and provide
>callbacks for that file to do its own I/O to load the kernel or
>whatever else is appropriate.
>

It's actually not a primary bootstrap. It's really very similar
to the SunOS 4.X secondary bootstrap, which in and of itself
was a miniversion of SunOS. The rationale for this was that it
needed to have NFS and a whole IP stack for diskless clients,
as well as 'dozens' of disk drivers.

A secondary boot that has all of this stuff in it is justified,
in my opinion, when you want to be able to do things like load
a primary/secondary from one media and boot or run diagnostics
from another. Since MILO sorta does this, it has some merit.

In the usual case, the aboot type of approach is probably more
appropriate: load physical blocks into ram, and boot only that
device/filesystem for which that boot block is constructed.