The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dan Cross <crossd@gmail.com>
To: Warner Losh <imp@bsdimp.com>
Cc: Paul Ruizendaal <pnr@planet.nl>, "tuhs@tuhs.org" <tuhs@tuhs.org>
Subject: [TUHS] Re: Unix install & "standalone" package
Date: Mon, 4 Sep 2023 14:21:21 -0400	[thread overview]
Message-ID: <CAEoi9W7q9qFLuoBkQBZ6UKZrnjTDeC-E3FzVhOQX82aT5co9oQ@mail.gmail.com> (raw)
In-Reply-To: <CANCZdfrJUB5TPQ3mi0deuniJihGTXCSG7UxFe4fEZ8-9KJpoiQ@mail.gmail.com>

On Mon, Sep 4, 2023 at 1:08 PM Warner Losh <imp@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.

  reply	other threads:[~2023-09-04 18:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04  9:57 [TUHS] " Paul Ruizendaal via TUHS
2023-09-04 14:53 ` [TUHS] " emanuel stiebler
2023-09-04 17:07 ` Warner Losh
2023-09-04 18:21   ` Dan Cross [this message]
2023-09-05 11:15   ` Paul Ruizendaal via TUHS
2023-09-05 14:15     ` Clem Cole
2023-09-05 17:03     ` Warner Losh
2023-09-04 14:44 [TUHS] " Norman Wilson
2023-09-04 14:55 ` [TUHS] " Vincenzo Nicosia
2023-09-04 17:20   ` Warner Losh
2023-09-04 19:05     ` Clem Cole
2023-09-05 17:03       ` Paul Winalski
2023-09-05 18:02         ` Clem Cole
2023-09-04 19:59     ` Theodore Ts'o
2023-09-04 23:51       ` Warner Losh
2023-09-04 17:18 ` Warner Losh
2023-09-04 22:10 ` Steffen Nurpmeso
2023-09-05 15:53   ` Steffen Nurpmeso
2023-09-06 17:50     ` Warner Losh
2023-09-07  0:11       ` Steffen Nurpmeso
2023-09-07 16:05         ` Warner Losh
2023-09-08 14:58           ` Theodore Ts'o
2023-09-08 13:56     ` Michael Kjörling
2023-09-08 23:38       ` Steffen Nurpmeso
2023-09-09 22:43         ` Steffen Nurpmeso
2023-09-11  4:10         ` Theodore Ts'o
2023-09-11 22:05           ` Steffen Nurpmeso
2023-09-05  1:07 ` Jonathan Gray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEoi9W7q9qFLuoBkQBZ6UKZrnjTDeC-E3FzVhOQX82aT5co9oQ@mail.gmail.com \
    --to=crossd@gmail.com \
    --cc=imp@bsdimp.com \
    --cc=pnr@planet.nl \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).