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 1391 invoked from network); 31 Dec 2022 21:54:41 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2022 21:54:41 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2ECEB423EB; Sun, 1 Jan 2023 07:54:17 +1000 (AEST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by minnie.tuhs.org (Postfix) with ESMTPS id 80DC2423EA for ; Sun, 1 Jan 2023 07:54:13 +1000 (AEST) Received: by mail-lj1-f182.google.com with SMTP id g14so25588942ljh.10 for ; Sat, 31 Dec 2022 13:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gnte2fpfe8+okFumKXAsdTjnBlRF1UCJHP2qKXvgoJo=; b=aLIF7agkRwN6zltzoy/tJChHepZZRQoIeRW4bXmBzXkbknHP9MOA1o8j1mM397uHXF WGTCie6ubdmgzLPU9SQZdeHMi4VtipR/4dslyiSJZAWJIIsXioEFjpSZ5XVFRcxrSvUy phaBCGIPAPJ1ZIdRksDpo6LZ6WETljzLZGebCaxJeIaZn+AbBQ7uLF4Zme9Ioyv0YgDC FnL3hreYvDzwlZl4fyRRATg4/0/0RFgX4StAS4hQMIKu7tngui4/9F2b9KYF8aWd7I13 lrFcafbiXpwRyPJl3b07CriC6BYT8ejmvhT+/NWYJ+AxKpsj6YmA8IRZSTCEz/CqpZVE M1UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=gnte2fpfe8+okFumKXAsdTjnBlRF1UCJHP2qKXvgoJo=; b=GGxWZ6fXlpZOa6yGMLcb3d+2PYwKqyMa1alh/MRBECqXv1+QOzXYoLd16RT103Tlx/ WnCHG/AtgLvaOFuhwAa+ZFfHCGOQnZ1VcvjwDemQmgGNKN8MriBGLNElwO2u4ga7RuMD ngXVzgwAsSoxClANa3+H/vRufroaaQsmNUTXVeb0wVdtNN28rvN9N73aXQ7o40dn0MEG eL7Y/ubu6IcCbTg1eXVsRshLZVomBPdTa7CZO0Qcr2Y0YcVPIRW4m3mcTQZ/C/xI6Vly G+kDgCa3YNEWs/5K20PvS4GgPrS3MSI63hGVX/TUQNciskHWQlmzaqjGjh+jGB6Y5yCg sMKA== X-Gm-Message-State: AFqh2kpxiAItHH1VGIjcAh3PxvDJyg+qLO36kXCqHIW9hFMElbMVdeSM neND73i2+CTTpxgWM67x44noo8S5OSrp8z8bpiQ= X-Google-Smtp-Source: AMrXdXtd9A6MTVx2m1/YCdFfDw61uqDyRj54qMwXSbdQpRq+vMARH8L0n7alDxWhDHTqZ78ziYEdaWvThhWCgbU7CuY= X-Received: by 2002:a2e:9bcb:0:b0:27f:d55c:7604 with SMTP id w11-20020a2e9bcb000000b0027fd55c7604mr637203ljj.196.1672523591816; Sat, 31 Dec 2022 13:53:11 -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:52:35 -0500 Message-ID: To: Clem Cole Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ORKSJMS6XZBDMNNWVCVMRK5ZZD2HED7L X-Message-ID-Hash: ORKSJMS6XZBDMNNWVCVMRK5ZZD2HED7L 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 4:39 PM Clem Cole wrote: > On Sat, Dec 31, 2022 at 4:11 PM Dan Cross wrote: >> 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. > > Fair enough. UEFI+ACPI started from BIOS and really should have been a = full re-think and write by senior OS people. Agreed. > It was not. The problem for us techies, is that doing that was not goin= g to save or make anyone $s. > > The problem for management was they wanted to keep the old BIOS around (t= hat's what the customer wanted - cheapest path forward) and unless there wa= s a reason to break from tradition, they were not going too. Apple could = (and did) but HP/Dell et al did not want too. Yeah. We canc'd it from our product (Oxide machines boot directly from the x86 reset vector and go almost immediately into Unix; no BIOS/UEFI+ACPI at all! Of course, there's a bunch of stuff that happens before the x86 cores come out of reset, but that's a different kettle of fish). We can get away with this because we control the hardware and the host software, and the unit of compute our customers interact with is a virtual machine, not the bare metal. When you control the horizontal _and_ the vertical, you can put it all in the host OS, where it arguably belongs. But in a world where software and hardware are completely decoupled? I don't know how to make the holistic boot approach work without a lot of system-specific code. It's obvious that you need some kind of system interface, and for most vendors, UEFI+ACPI is there and supported by the chip and firmware vendors, so it's the default. No one ever got fired for using UEFI/ACPI, I guess. - Dan C.