From: Marc Donner <firstname.lastname@example.org>
To: "Theodore Ts'o" <email@example.com>
Cc: Paul Ruizendaal <firstname.lastname@example.org>,
The Eunuchs Hysterical Society <email@example.com>
Subject: [TUHS] Re: Porting the SysIII kernel: boot, config & device drivers
Date: Sat, 31 Dec 2022 17:55:32 -0500 [thread overview]
Message-ID: <CALQ0xCBb8Jp4K8YDYhYysrgtqH_w_iCrLz_snox_2DUbZ9XbMQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]
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:
On Sat, Dec 31, 2022 at 5:38 PM Theodore Ts'o <firstname.lastname@example.org> 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
> 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
[-- Attachment #2: Type: text/html, Size: 3455 bytes --]
next prev parent reply other threads:[~2022-12-31 22:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-30 18:25 [TUHS] " Paul Ruizendaal
2022-12-30 18:56 ` [TUHS] " Steve Nickolas
2022-12-31 14:59 ` Dan Cross
2022-12-31 19:08 ` Clem Cole
2022-12-31 21:10 ` Dan Cross
2022-12-31 21:39 ` Clem Cole
2022-12-31 21:52 ` Dan Cross
2022-12-31 23:25 ` Dave Horsfall
2023-01-01 1:02 ` Rob Pike
2023-01-01 1:16 ` George Michaelson
2023-01-01 1:40 ` Larry McVoy
2023-01-01 2:29 ` Warner Losh
2023-01-01 1:24 ` Larry McVoy
2022-12-31 22:38 ` Theodore Ts'o
2022-12-31 22:55 ` Marc Donner [this message]
2023-01-01 3:55 ` Dan Cross
2023-01-01 20:29 ` Paul Ruizendaal
2023-01-01 21:26 ` G. Branden Robinson
2023-01-01 21:31 ` Rob Pike
2022-12-31 21:11 ` Paul Ruizendaal
2022-12-31 20:02 ` Paul Ruizendaal
2022-12-31 21:04 ` Warner Losh
2022-12-31 21:41 ` Dan Cross
2023-01-01 3:08 ` Warner Losh
2023-01-01 4:40 ` Dan Cross
2023-01-01 8:05 ` Jonathan Gray
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).