From: "Theodore Ts'o" <firstname.lastname@example.org>
To: Dan Cross <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:38:09 -0500 [thread overview]
Message-ID: <Y7C50dGWZ6yFDX74@mit.edu> (raw)
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.
next prev parent reply other threads:[~2022-12-31 22:38 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 [this message]
2022-12-31 22:55 ` Marc Donner
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).