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
>