From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15522 invoked from network); 3 Jan 2024 04:30:50 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2024 04:30:50 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 59D7443E77; Wed, 3 Jan 2024 14:30:45 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id B5EB043E76 for ; Wed, 3 Jan 2024 14:30:42 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-116-110.bstnma.fios.verizon.net [173.48.116.110]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 4034UaOh005479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Jan 2024 23:30:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1704256238; bh=vSRTvvwaNWWlashss5DpDiyyuuI51GO/ZEc/7ydFX78=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=WxhrhRQ+KBIycsIHP5DSHzxV7UVPQMbNMlBpZSaGI/PNhLWg1IRQ9MAF19SnXiPw/ eWq8PqA83ULAf40bsCWV4PUPRJ7iyPBB/QS14DMpyjJYk+1J5uqWRY/Fw4ySZ2HUWR zjyy0TdouRraX/MGSajHYLJb6wNl5Re7S7PzLF3RSRkblNSpTxcSazlGfM+/G4w0px CKYzrFOXgrGb04ERDYF3uH5QR2OTG+bfvEMvnJYqwkuuiOkHVetQWyG1sEevkQWhSm YlOzjy6jBsuwwg6i7guyp7PEfm6a2LpbifHbr3gFhrGng0B7nVXdkeH/TqkyHKsxrx gxC9U/k8Y0xag== Received: by cwcc.thunk.org (Postfix, from userid 15806) id DF03915C17F9; Tue, 2 Jan 2024 23:30:36 -0500 (EST) Date: Tue, 2 Jan 2024 23:30:36 -0500 From: "Theodore Ts'o" To: Warner Losh Message-ID: <20240103043036.GB108362@mit.edu> References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-ID-Hash: WZVHGSJYOFBRTU2GFDS7V37LPFNCEER3 X-Message-ID-Hash: WZVHGSJYOFBRTU2GFDS7V37LPFNCEER3 X-MailFrom: tytso@mit.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Unix Heritage Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Question about BSD disklabel history List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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