buz@dip.eecs.umich.edu (Greg Buzzard) (02/07/91)
Please excuse the fact that I had to post this from U. Mich.
and not my home site... (this is scheduled to change soon,
right Dave?)
Let me clarify a few points from an earlier posting about the
OBIOS (btw, this work is now going on under the auspices of IEEE
as P1256)...
(i) if there are multiple instances of the same device
unit, there will be one copy of the code and multiple
copies of the unit instance data. The unit instance data
contains device state and configuration info. E.g., for a
serial device:
(1) current baud rate, bits/char, parity.
(2) interrupt state, device unit state (i.e. enabled disabled)
(3) device address
(4) input clock frequency, etc.
There also seems to be some confusion over reentrancy.
The BIOS functions do not block, they typically either
(1) immediately complete their request, or
(2) initiate the I/O and indicate the time at which
completion is expected.
In either case, the functions return immediately. The
amount of time that a client may be blocked by reentrancy
restrictions is short. Additionally, the blocking is only
for requests to a *specific* instance of a device unit (not
on the single copy of the code that is shared by all similar
units). The point of making the client provide the protection
against reentrancy is to avoid having to have knowledge of
O.S. policies (i.e., scheduling, resource allocation, etc) in
the OBIOS -- OBIOS implementation should be O.S. independent.
(ii) The key point of a standard is interoperability. This implies
that "rules" need to be adhered to. If there is a problem with
the rules, then the rules need to be fixed -- not ignored.
Greg Buzzard internet: buz@eng.ready.com
Chairman, IEEE P1256
Ready Systems
470 Potrero Ave. phone: 408/736-2600
Sunnyvale, CA 94086