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,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8968 invoked from network); 31 Dec 2022 22:56:57 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2022 22:56:57 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id CBCFC42403; Sun, 1 Jan 2023 08:56:51 +1000 (AEST) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by minnie.tuhs.org (Postfix) with ESMTPS id 4E4C342400 for ; Sun, 1 Jan 2023 08:56:44 +1000 (AEST) Received: by mail-ot1-f51.google.com with SMTP id p17-20020a9d6951000000b00678306ceb94so15173436oto.5 for ; Sat, 31 Dec 2022 14:56:44 -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=RZxKgNKb7/78YgKVBfhEZeObHotgqcxOn4Pox5oPKQg=; b=QY6CHcBygH8J7WWHPcUYIzH5+Td6sqX168TYfKkcp3wF825aswMI9sTTV+KM6/A7e+ uiayloPZZ3vlwjvJJxEipLy28v2J7404dukA00IWqDujj54cNqlRuyieV+5tkV+GBW0d ahBLLJKnq+V2HOjHOVKeXH/xGRvJkyii+G0xeh/oq7ryVN321J/AhyoMRBtaw4sn1JbI T6oU3nQBJzaDeFL1k6dsORYclOHh17OhGoau0N0ifC4TObmcsblDQWSeRouzcBBhZJsC 4k5QjUjydBpJMwPKH2e7z6WcFExQEdaWKAMPjQFmhld+FSHmmP3gXHbJCL7hCLfnE1cZ Nj0A== 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=RZxKgNKb7/78YgKVBfhEZeObHotgqcxOn4Pox5oPKQg=; b=TpS4aLFqXk87fDQVKiiujmpUvLFZGvGsDpdUlOHoy/5JYh5KnkYSM+iKqSo68hk5b+ svbY5xFzcFoSa20yyQXqO8P7aU+4v6lxKFb70OffvhmgE8puyh+fRBISHkufUZkqIqv/ bAK6RXN/qy67mqlstMEJj0qRrRaU1cN+fXrRZPFqWGfhksPr2zRMifR8KgDvdfHwOMAA /ZImcMq24YgRuyLxEbRde7fzZfcsdIhNXvlQXguNzOq4wzWTz9ioOfAfUsHS6r02wxnY PzbdfEpZBe1gHQXq1v4koP7HEkyrz5Yny2xnqRJyYbU5sx11qCuR3/rixIYlfCliXrmH 3SjA== X-Gm-Message-State: AFqh2koMD50GZB3kM4MJ0lgKs7uCUAeSh/GANadCWQQ20v+1CDiDzZWj HECLTMy42YXCIjC7Uag+zylMHjtD9BCoq/wrRaA= X-Google-Smtp-Source: AMrXdXutYr7IC/D3Ryx5YE8R3R96P88Mrr2hGS1sL5zzkkGiXP6y065aum1dBrOx2a8HdQL3a6+dr36K9699DMpvJM0= X-Received: by 2002:a05:6830:20c1:b0:661:943e:92e2 with SMTP id z1-20020a05683020c100b00661943e92e2mr1916007otq.362.1672527343573; Sat, 31 Dec 2022 14:55:43 -0800 (PST) MIME-Version: 1.0 References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> In-Reply-To: From: Marc Donner Date: Sat, 31 Dec 2022 17:55:32 -0500 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="00000000000030e1c505f1279eec" Message-ID-Hash: R6K26JVWX63NUGFRD2EFICFJPKSXFDAN X-Message-ID-Hash: R6K26JVWX63NUGFRD2EFICFJPKSXFDAN X-MailFrom: marc.donner@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: --00000000000030e1c505f1279eec Content-Type: text/plain; charset="UTF-8" This is not precisely what I remember, but I remember at USENIX when there was a talk about the Open Boot work, someone sang a song. I looked for the song, but only found this page which doesn't read right to me: https://everything2.com/title/The+Open+Firmware+Song ===== nygeek.net mindthegapdialogs.com/home On Sat, Dec 31, 2022 at 5:38 PM Theodore Ts'o wrote: > On Sat, Dec 31, 2022 at 04:10:47PM -0500, Dan Cross wrote: > > >> 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. > > More generally, we need to make sure we're all on the same page with > respect to requirements. What are we trying to do with respect to > abstraction? Do we just want to inform the OS about Port and MMIO > addresses, interrupts, etc, with the device driver living in the OS? > Or are are we trying to move the entire device driver plus bus > configuration/attachment probing into some kind of separate firmware > layer which is decoupled from the rest of the OS? > > How important is portability? Does this hardware abstraction layer > and/or firmware need to work with major legacy OS's such as Windows 95 > (still in use by the US Government)? Windows 10? NetBSD? Linux? > Or just only new research OS's? > > How important is performance? And does it need to support OS's that > might want to support interesting features, such as say, confidential > computing? IOMMU's? DMA from a storage device directly into memory > which is accessable over RDMA via Infiniband or iWARP or to GPU > memory? > > Or are we just trying to solve the problem of loading the OS, or maybe > just initial bootstrap portion of the OS, where performance or support > for more exotic memory use cases might not be as important? > > If we don't agree on exactly what problem that we are trying to solve > with BSD-style autoconfig, vs UEFI vs ACPI vs the x86 BIOS vs CP/M's > BIOS, etc. Otherwise, the risk that we'll end up talking past one > another, or delivering a solution that we're happy with, but others > are not, is quite high IMHO. > > - Ted > --00000000000030e1c505f1279eec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is not precisely what I remember, but I re= member at USENIX when there was a talk about the Open Boot work, someone sa= ng a song.=C2=A0 I looked for the song, but only found this page which does= n't read right to me:=C2=A0https://everything2.com/title/The+Open+Firmware+Song


On Sat, Dec 31, 2022 at 5:38 PM Theodor= e Ts'o <tytso@mit.edu> wrote= :
On Sat, Dec 31= , 2022 at 04:10:47PM -0500, Dan Cross wrote:
> >> 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 di= scover/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 in= to
> solving the wrong problem.

More generally, we need to make sure we're all on the same page with respect to requirements.=C2=A0 What are we trying to do with respect to
abstraction?=C2=A0 Do we just want to inform the OS about Port and MMIO
addresses, interrupts, etc, with the device driver living in the OS?
Or are are we trying to move the entire device driver plus bus
configuration/attachment probing into some kind of separate firmware
layer which is decoupled from the rest of the OS?

How important is portability?=C2=A0 Does this hardware abstraction layer and/or firmware need to work with major legacy OS's such as Windows 95<= br> (still in use by the US Government)?=C2=A0 Windows 10?=C2=A0 NetBSD?=C2=A0 = Linux?
Or just only new research OS's?

How important is performance?=C2=A0 And does it need to support OS's th= at
might want to support interesting features, such as say, confidential
computing?=C2=A0 IOMMU's?=C2=A0 DMA from a storage device directly into= memory
which is accessable over RDMA via Infiniband or iWARP or to GPU
memory?

Or are we just trying to solve the problem of loading the OS, or maybe
just initial bootstrap portion of the OS, where performance or support
for more exotic memory use cases might not be as important?

If we don't agree on exactly what problem that we are trying to solve with BSD-style autoconfig, vs UEFI vs ACPI vs the x86 BIOS vs CP/M's BIOS, etc.=C2=A0 Otherwise, the risk that we'll end up talking past one=
another, or delivering a solution that we're happy with, but others
are not, is quite high IMHO.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 - Ted
--00000000000030e1c505f1279eec--