The Unix Heritage Society mailing list
 help / Atom feed
From: Warner Losh <imp@bsdimp.com>
To: Clem Cole <clemc@ccc.com>
Cc: The Unix Heritage Society <tuhs@minnie.tuhs.org>,
	Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: [TUHS] Pre-init initialization
Date: Wed, 7 Aug 2019 10:40:06 -0600
Message-ID: <CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2PjoKqSfEeBu9pJuOOR772hDhwmUh_k0TbYZU-WTnHSNA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]

The move into RAM disks happened as memories grew. This obviated the need
to copy a filesystem to a new disk's swap space and then use that to really
install the system.

Kernels with bundled RAM disks were a thing in BSD for a long time, though
I'm unsure when that functionality entered the code stream. I know the
early versions of FreeBSD's installer ran out of a RAM disk loaded off
floppies, though that's not the same as initrd since there never was a
pivot to something else: just a reboot to boot the real thing.

FreeBSD, at least, has the functionality to also do a RAM disk to get
things configured enough to pivot to the real disk on boot, but that's a
niche operation there: most everybody just boots off / directly without the
initrd-like thing. It's rarely needed, but it's one of those things that
when it is needed, it's really needed, which is why one can do it.

FreeBSD has an interesting 'tertiary loader' that plays a similar role to
initrd. It orchestrates loading of modules, setting tunable parameters and
launching the kernel. It's grown up to be a mini-kernel stand-alone
program, but as the real kernel is now 28MB, the boot loader leverages off
'boot services' or other well-known interfaces to weigh in at only a few
hundred k. This has proven to be both a blessing and a curse at times,
however.

Warner

On Wed, Aug 7, 2019 at 7:05 AM Clem Cole <clemc@ccc.com> wrote:

> A couple of the commercial systems did this for sure. Linux definitely
> picked it up from UNIX practices, although I have no idea/memory of who did
> it first.  We used the idea at Stellar (Stellix) and at Masscomp (RTU).
> IIRC, a couple of others like Pyramid made have created a RAMFS - but it
> was kicking around the UNIX community for a fairly long time - certainly in
> the late 1970s - *i.e.* post V7.
>
> FWIW: V7 had /stand which was a funky UNIX-like standalone system that
> some applications could be compiled.  The problem was that it was a little
> different so you would end up seeing #ifdef STAND in code for things like
> fsck, fsdb, even cat.  At Masscomp we ended up with three target
> environments for a couple of the system maintenance utilities: the OS,
> /stand and the boot ROMS.   This was expensive/a PITA to maintain and keep
> straight, and in the case of the boot ROM, space was a huge problem.
>
> The RAMFS idea was created to get rid of at least /stand and IIRC we were
> able to drop a number of utilities out of the boot ROM.  I'm not sure how
> far they took it.   I left for Stellar and it was always the way Stellix
> booted.
>
>
>
> On Tue, Aug 6, 2019 at 7:47 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>> Do, or did, anything other than Linux use a concept of an initramfs /
>> initrd to create a pre-(main)-init initialization environment to prepare
>> the system to execute the (main)-init process?
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
>>

[-- Attachment #2: Type: text/html, Size: 4055 bytes --]

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06 23:46 Grant Taylor via TUHS
2019-08-07  1:22 ` Andrew Warkentin
2019-08-07 13:04 ` Clem Cole
2019-08-07 16:40   ` Warner Losh [this message]
2019-08-08 13:31     ` Theodore Y. Ts'o
2019-08-09  1:52       ` Grant Taylor via TUHS
2019-08-10  0:23         ` Theodore Y. Ts'o
2019-08-10  2:28           ` Grant Taylor via TUHS
2019-08-10  4:21             ` Kevin Bowling
2019-08-10  4:50               ` Grant Taylor via TUHS
2019-08-10  4:52               ` Adam Thornton
2019-08-08 13:43     ` Clem Cole
2019-08-08 18:59       ` Warner Losh
2019-08-09  1:46   ` Grant Taylor via TUHS
2019-08-09  2:15     ` Warner Losh
2019-08-09  6:43       ` Kevin Bowling
2019-08-10  1:45 ` Chris Hanson

Reply instructions:

You may reply publically 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='CANCZdfpPbnB+8GGbzT65dRigDEX=i4qQEsy9MKyV3TnxS8-v2w@mail.gmail.com' \
    --to=imp@bsdimp.com \
    --cc=clemc@ccc.com \
    --cc=gtaylor@tnetconsulting.net \
    --cc=tuhs@minnie.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

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox