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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28786 invoked from network); 31 Dec 2022 21:13:02 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2022 21:13:02 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id E36A6423EF; Sun, 1 Jan 2023 07:12:29 +1000 (AEST) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by minnie.tuhs.org (Postfix) with ESMTPS id B20AF423EC for ; Sun, 1 Jan 2023 07:12:25 +1000 (AEST) Received: by mail-lf1-f45.google.com with SMTP id b3so36504686lfv.2 for ; Sat, 31 Dec 2022 13:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z44iKot+O1vuek4wublIk5qdIPNsdO1tyYI9qKr7Jws=; b=Rzs6l6F1IuExp2qshyLqHTdPB96cdnRZUJyYUP598Ql8x4qrch/Lcx9M26ifD953Rp Rq9DFXRrONNmO8JH/IReI9csYXy1c9iNbo4iD6Zanrbk/rllvaLu82Lv5e9/vRmXo/IU 6viGWqV1cNTnckIey3Lz/PAl9fUlWX/Qm96X+YzDjWUbqXPA8KEPnVnUUvZ9Vz3A2NMh JGHbQVB0CDmoTasCwyYa+g8AP2/uJB7PGaef6FcLLNhAtc0apeSntv4EO6kBa7fwI0WS 0O9vskEGKwK+4RXbH96UTkBd8Z6HlN+mYFivrQRPTFPWryQbhwOFbGZIxjSbJIDbEJ0a mxDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=z44iKot+O1vuek4wublIk5qdIPNsdO1tyYI9qKr7Jws=; b=QfKp79o4AJxEhphXAu49q8OalelFGcppo2I7PFD3ZRkxk672noCbzDktGYAAGB54Ij N0qzIlpOxkQH8HKOCJJISs5wDIwx449lpc7Mzf92yf40F6kfXclyNAvVciw1yYRb0Oh2 hnQ3yWuwpa90cerPwd6QKHz1KoFG6qlsdrEJfb3IF0+pgnjTvtxSdn85yKugRldj8JhS pX1C9bdIPQANjFQOTdgs5EsJfcTCImAXH0mDMgEUIvMzde2JtzvQzhd3nsDyWV7/+w27 DMrhbIIoXb5q724PCrEmCZ3nyqKKdmzD3h684KHogqJq9OJ9iD3lqZosrL/DqRZIX+wO GKmQ== X-Gm-Message-State: AFqh2kqLpcxxvfdvU6drWyxjkz/2MB9tSiWkgz5n2uYur61YxHzAwegB hyT/WkOfJGpgo5iulx6hWZ1XJXPdUqNcq7cLPMI= X-Google-Smtp-Source: AMrXdXvI/gPMa3dzlcij7X839Q06769bzb7+PYEM5YzaLitoS0H50gtY5Qr83srFFKsdmoq6+r9pA0aPZOVQvUr51Z4= X-Received: by 2002:ac2:5c5a:0:b0:4cb:154d:2178 with SMTP id s26-20020ac25c5a000000b004cb154d2178mr610957lfp.367.1672521083870; Sat, 31 Dec 2022 13:11:23 -0800 (PST) MIME-Version: 1.0 References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> In-Reply-To: From: Dan Cross Date: Sat, 31 Dec 2022 16:10:47 -0500 Message-ID: To: Clem Cole Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: FGEBKLIFNACZTFJCYHWHKBIRATSMFDPT X-Message-ID-Hash: FGEBKLIFNACZTFJCYHWHKBIRATSMFDPT X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Paul Ruizendaal , The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Porting the SysIII kernel: boot, config & device drivers List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sat, Dec 31, 2022 at 2:08 PM Clem Cole wrote: > On Sat, Dec 31, 2022 at 10:02 AM Dan Cross wrote: >> [snip] >> SBI was/is an attempt to define a common interface to different >> devices using RISC-V CPUs, but it's growing wildly and tending more >> towards UEFI+ACPI than something like OpenBoot, which was much >> simpler. > > UEFI+ACPI got/gets a bad rep because of the original IBM BIOS implementations. I'm going to push back on this slightly: UEFI+ACPI get a bad rap because, well, they're really pretty bad. Oh sure, some things are reasonable: the ACPI table formats aren't awful. But I've been inside a couple of these now and phew golly, they stink pretty badly. The code is poor quality, and encourages running blobs of really dubious provenance. See below.... >> In general, the idea of a BIOS isn't terrible: provide an interface >> that decouples the OS and hardware. > > Exactly - the idea is actually a good one. But the problem was the BIOS designed/implemented by HW people, but OS folks. Things like concurrency minimum use of the CPU was not in the higher order bits. > >> But in practice, no one has come >> up with a particularly good set of interfaces yet. Ironically, >> BSD-style autoconfig might have been the best yet. > > ??Maybe because it was OS types who knew what the OS needed to discover/report/deliver back from the HW. Perhaps this is what it is, but I think taking a step back and looking at the problem more generally, it's because they're mutated into solving the wrong problem. Consider AML: isn't this something that ought to be handled in, I don't know, a device driver? Yes, that driver may need access to some platform-specific firmware to abstract the details, but an entire virtual machine running random code to provide abstractions for the firmware writers who are running, basically, a parallel operating systems is a bit on the nose. This goes way beyond OpenBoot's forth modules on option ROMs (which were kind of a nifty idea for device discovery and such things). Mothy Roscoe gave a really interesting keynote at OSDI'21: https://www.youtube.com/watch?v=36myc8wQhLo I love how he describes the interfaces we have now as having "congealed." But in some ways, UEFI+ACPI are the antithesis of what the OS should be doing. - Dan C.