The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Warner Losh <imp@bsdimp.com>
Cc: The Unix Heritage Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Question about BSD disklabel history
Date: Tue, 2 Jan 2024 23:30:36 -0500	[thread overview]
Message-ID: <20240103043036.GB108362@mit.edu> (raw)
In-Reply-To: <CANCZdfr7Z=dhW2i9izv4hi69Sigh=6tB05_gksmcZcvf3RDDcA@mail.gmail.com>

On Tue, Jan 02, 2024 at 08:57:34PM -0700, Warner Losh wrote:
> 
> Indeed. I got to deal with all of that, and more. I have finished writing
> LinuxBoot support for FreeBSD. The normal kexec-tools, u-root, etc aren't
> sufficient for FreeBSD because FreeBSD's kernel expects the boot loader
> to setup a number of meta-data items that go with the kernel that include
> all the information about the system that the kernel simply can't get once
> you've entered long mode...
> 
> Even with LinuxBoot, you are booting with UEFI, albeit with a much small
> much smaller UEFI.

Yeah, one of the older names of LinuxBoot was NERF (Non-Extensible
Reduced Firmware).  I was confusing LinuxBoot with coreboot, which is
used on all ChromeOS devices after 2012, and which completely doesn't
use any magic binary blobs supplied by the mainbord vendor.  The
tradeoff is that coreboot only supports a very restricted set of
hardware, since it has to do all of the things that are "normally"
done by the vendor's binary blobs to initialize the hardware devices,
etc.  This only works if you have very tight control over hardware,
and you have enough influence that you can lean on the mainboard
vendors to allow the low-level programming details of their devices to
be released in open source code which that can be independently
verified and digitally signed by the OS vendor (such as Google in the
case of ChromeOS).

Many hyper-scale cloud companies will tend to use coreboot or related
software instead of UEFI.  A public/published example of this is
Facebook's Open Compute Project.

It *is* nice not to have to deal with UEFI at all, if you're lucky
enough to be able to use hardware where it's not necessary....  Of
course you won't be able to run Windows on those systems, but some
would consider that a feature.  :-)

					- Ted

  parent reply	other threads:[~2024-01-03  4:30 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-31 17:30 [TUHS] " Grant Taylor via TUHS
2023-12-31 17:38 ` [TUHS] " arnold
2023-12-31 20:07   ` Warner Losh
2024-01-01  0:13     ` Bakul Shah
2023-12-31 20:27   ` Phil Budne
2023-12-31 21:02     ` Warner Losh
2024-01-01  0:26   ` Grant Taylor via TUHS
2024-01-01  2:22     ` Warner Losh
2024-01-01  3:24       ` Grant Taylor via TUHS
2023-12-31 21:31 ` Clem Cole
2023-12-31 22:07   ` Warner Losh
2024-01-01 16:00     ` Clem Cole
2024-01-02 18:49       ` Warner Losh
2024-01-02 19:30         ` Chet Ramey
2024-01-02 20:07           ` Clem Cole
2024-01-02 19:50         ` Dan Cross
2024-01-02 19:55           ` Jim Capp
2024-01-02 20:11             ` Dan Cross
2024-01-02 20:30           ` Dan Cross
2024-01-02 20:50             ` Clem Cole
2024-01-02 21:04               ` Dan Cross
2023-12-31 22:46   ` G. Branden Robinson
2023-12-31 23:06     ` Larry McVoy
2023-12-31 23:37       ` Al Kossow
2023-12-31 23:41       ` Alec Muffett
2024-01-02 20:48       ` Dan Cross
2024-01-02 21:17         ` John Cowan
2024-01-03  3:33         ` Theodore Ts'o
2024-01-03  3:57           ` Warner Losh
2024-01-03  4:03             ` Warner Losh
2024-01-03  4:30             ` Theodore Ts'o [this message]
2024-01-03  5:10               ` Warner Losh
2024-01-03 15:56                 ` Dan Cross
2024-01-03 16:37                   ` Theodore Ts'o
2024-01-03 16:41                     ` Dan Cross
2024-01-04  8:42                     ` arnold
2024-01-04 18:26                       ` Kevin Bowling
2024-01-03 14:39           ` Dan Cross
2023-12-31 23:08     ` Phil Budne
2023-12-31 23:37       ` G. Branden Robinson
2023-12-31 23:59         ` Warner Losh
2023-12-31 23:50     ` G. Branden Robinson
2024-01-01  0:09       ` Al Kossow
2023-12-31 21:55 Norman Wilson

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=20240103043036.GB108362@mit.edu \
    --to=tytso@mit.edu \
    --cc=imp@bsdimp.com \
    --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).