In message <199807300233.TAA07950@shell17.ba.best.com>, Todd Whitesel writes:

>This seems nice, but to guarantee performance you need more than just API
>calls defined. How are DMA channels and buffers going to be managed, for
>instance.

And interrupts too.


> On a related topic, F-code looks promising,
>but is it considered by anyone to be adequate for more than just booting?

It's pretty slow because OpenFirmware is designed around a polling-only
driver architecture but it can be (and has been) done.  Most FCode
drivers are fairly dumb as they cannot rely on interrupts which are
system dependent, and OF doesn't specify how to deal with them.

OF actually does have a fairly clean way to handle bus layers and
DMA-safe buffers but doesn't say anything about DMA channels or
interrupts.


>My only real complaint with the concept of the motherboard BIOS configuring
>everything is that the results must be safely probe-able by the O/S without
>ever talking to the BIOS again, or the BIOS must provide a data structure
>that describes what it did.

Those are pretty much the choice you have to have.  Even with I2O, the
kernel is still going to need to know this information to setup its
devices (like under /dev), select a console, and figure out which device
"/" is on, and so on.

So instead of probing the devices itself or asking the BIOS or asking
OpenFirmware, the kernel has to ask I2O (or something else), yes?


PCI is pretty easy to re-probe if you're not looking to allocate BARs or
load FCode ROMs.  USB and Firewire look much nastier, especially with
their hot-plug features.  The OS ends up needing a pretty complete set
of configuration code but the firmware also needs to do this to figure
out where to boot from and what device to use as the console.

The way things are going, it may well be easier to simply burn *BSD into
the ROM and let it be the firmware as well just to avoid replicating
code. :-)


	-- Parag