The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Marc Donner <marc.donner@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Paul Ruizendaal <pnr@planet.nl>,
	The Eunuchs Hysterical Society <tuhs@tuhs.org>
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)
In-Reply-To: <Y7C50dGWZ6yFDX74@mit.edu>

[-- 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:
https://everything2.com/title/The+Open+Firmware+Song
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Sat, Dec 31, 2022 at 5:38 PM Theodore 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
> 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
>

[-- Attachment #2: Type: text/html, Size: 3455 bytes --]

  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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALQ0xCBb8Jp4K8YDYhYysrgtqH_w_iCrLz_snox_2DUbZ9XbMQ@mail.gmail.com \
    --to=marc.donner@gmail.com \
    --cc=pnr@planet.nl \
    --cc=tuhs@tuhs.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).