[LinuxBIOS] Specifications

[Eric W. Biederman]

"ron minnich" <rminnich at gmail.com> writes:

> This should all be so simple.
>
> The original idea was that LB would turn on dram, call OS, done. OS
> would do all config space.
>
> Then, turned out linux can't configure unconfigured PCI BARs. And, we
> needed to do some PCI config for SPD.
>
> So, LB starts doing ALL PCI config -- no way out.
>
> Then, turns out some devices put things in IO space that affect PCI
> config space. YUCK! But we have to start doing things in IO space for
> PCI config space.
>
> Then, turns out that many IRQ tables are wrong. So, we start setting IRQs.
>
> And so on and so on ....
>
> Really, I think LB should only do those things the OS can not possibly
> do. The "OS can't do" is a boundary we hoped would be very solid and
> immovable. The problem is, buggy hardware, and buggy kernels, make
> that boundary very, very hard to find. And, both hardware and kernels
> keep changing --> the boundary is flexible. In 1999 I thought there
> would be simple, hard rules; I was quite wrong.

I think we can have a definition that is slightly more stringent.
LinuxBIOS should take care of the motherboard specific details, and
ensure architectural hardware shows up at the architectural defined
location.

None of this suggests we will setup any of this hardware for use
other than setting it's bars.

It makes the responsibility of the OS/payload to figure out how to
use everything that is not hardware specific.

> Every new piece of hardware seems to push the boundary around in some
> way. It is difficult sometimes to know what to do. But, in the end, LB
> should really try to do almost nothing, and let its payload(s) do
> almost everything.

Yep.

Eric