The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Kevin Bowling <kevin.bowling@kev009.com>
To: Warner Losh <imp@bsdimp.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>,
	Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: [TUHS] Pre-init initialization
Date: Thu, 8 Aug 2019 23:43:09 -0700	[thread overview]
Message-ID: <CAK7dMtAWK+SahB+KQ8qHQcN+0krRtMtvCVM-=560hC_-tEJWsw@mail.gmail.com> (raw)
In-Reply-To: <CANCZdfpZgYTBWjMpKkEF8sseAo-62h50ERJsTQSvF2Fn_G1Gjg@mail.gmail.com>

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

On Thu, Aug 8, 2019 at 7:16 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>> On 8/7/19 7:04 AM, Clem Cole wrote:
>> > FWIW: V7 had /stand which was a funky UNIX-like standalone system that
>> > some applications could be compiled.
>>
>> I've seen /stand on a few systems (I think SCO OpenServer and / or
>> UnixWare) but never really knew what it was for.  I think I had naively
>> assumed it was associated with the kernel and / or booting.
>>
>> Now I'm somewhat more curious what it was.  Was it a simplified version
>> of the OS with minimal utilities with fewer dependencies so that the
>> system could boot and load more features.
>>
>
> Yes. There was a library that implemented much of the unix API in a
> simplified way that ran on bare metal.
>
> I thought that Linux's initramfs / initrd had the usual suspect files /
>> utilities copied from /.  So the idea that a utility in /stand would be
>> different from the same utility in / seems strange to me.
>>
>
> They are because there was no kernel for them to run under. They were
> similar, but if you go look at the sources, they are different.
>
> > 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.
>>
>> Ya.  I can see how that would be a PITA to maintain.
>>
>
> FreeBSD, NetBSD and OpenBSD all implement some version of this. FreeBSD
> has it in src/stand in honor of V7 stand. I did that when I integrate /
> rewrote the GSoC project to bring Lua scripting to the boot loader. The
> other BSDs have it split between sys/boot and lib/libs. FreeBSD uses it to
> implement the rich boot loader which knows how to load off a lot of
> different file systems and BIOS interfaces. Net/OpenBSD use it more
> modestly in their boot loaders, but have a few standalone programs for
> things like bootstrapping VAXen.
>

Yeah NetBSD has little gadgets in the ports stand directory for booting odd
hardware.  It would be preferable to have something like FreeBSD’s loader
everywhere, but that would be hard to cover to the swath of ports NetBSD
has, and would still require chain loading gadgets for many platforms.

>

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

  reply	other threads:[~2019-08-09  6:44 UTC|newest]

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
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 [this message]
2019-08-10  1:45 ` Chris Hanson

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='CAK7dMtAWK+SahB+KQ8qHQcN+0krRtMtvCVM-=560hC_-tEJWsw@mail.gmail.com' \
    --to=kevin.bowling@kev009.com \
    --cc=gtaylor@tnetconsulting.net \
    --cc=imp@bsdimp.com \
    --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
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).