On Mon, Sep 4, 2023 at 1:08 PM Warner Losh <imp(a)bsdimp.com> wrote:
[snip]
There's a port of /boot/loader to illumos too, but I don't know
if it is the default, or just available. So I'll not chat about it more.
I can confirm that it is the default on i86pc, though not universally.
At Oxide, for example, we boot directly into a very small loader held
in flash that has a compressed cpio archive containing the kernel and
a few necessary kernel modules compiled into it (as a byte blob); we
uncompress that blob into physical memory, locate and load the kernel
like a normal ELF binary, and jump to the kernel's ELF entry point,
passing a few basic arguments (notably, the location and length of the
cpio archive in physical memory). Entry to the kernel is thus in
64-bit mode with paging enabled.
So the original 'standalone' environment
where you had one program running on a system has evolved
into either a rich boot loader environment that lets one do a lot to decide what kernel
to load, or towards
having a minimal selection of unix programs faster and using /bin/sh or similar to do
scripting. These
reduced environments are often called standalone, though all they share just the name
with the earlier
'stand' programs: they are full unix programs, but with reduced feature sets
and 'linker magic' to package
them in a way that's faster, smaller, etc (eg all in one binary). FreeBSD's
boot loader is an outgrowth
of the original standalone env, by way of a port of NetBSD's libsa.
I suspect in the future, we'll see more and more of a trend for low-level init and
then handing off to some
built-in kernel (be it Linux, BSD-based (there's now kexec), or whatever) to reuse
more of the vetted code
rather than re-inventing Unix inside the boot loader (which is a valid criticism of
FreeBSD's boot loader,
though it's rich feature set is what you get for the complexity).
Does that answer the prompt? Should I try to make this into more of a retrospective paper
and actually
do the research on the areas I was hand-wavy about?
That would be interesting.
I can still remember booting IBM 6150 RTs into a miniroot environment
and using that to create and initialize filesystems when installing
AOS (4.3BSD for the RT) back in the day. To my mind, the standalone
programs were always oriented towards solving the related problems of
bootstrap initialization onto a fresh machine, and disaster recovery
when things were really, really messed up.
As I recall, the RT miniroot could either load from tape, or one could
`dd` it into swap and boot from that. In either case, I seem to recall
it was copied into memory and run as a RAM disk. The idea of busy-box
like "a bunch of utilities compiled into the same binary" was to save
space, particularly since this would be copied into RAM; even with
demand paging, redundant copies of bits from `libc` in each binary
were a waste for what was intended to be a minimal environment anyway.
- Dan C.