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