[Coco] RBF and LSN0

[Chuck Youse]

On Tue, 2008-09-23 at 01:46 -0400, Robert Gault wrote:

>   RBF can't read LSN0 itself if the above philosophy is to be maintained 
> because RBF does not know how to talk to any specific RB device. There 
> is no duplication of code in the above scheme because the driver codes 
> are essentially unique to specific hardware.

I'm not suggesting that RBF read LSN0 itself.  I am saying that RBF
calls the driver READ function with a B:X set to 00:0000 and with the
destination buffer pointer set in the path descriptor (PD.BUF).  It also
knows where the drive table is located in the driver's static area (RBF
fixes the base address), which is where the LSN0 information goes.
Thus, RBF has all the information required to perform this update
itself, and there is nothing hardware-specific going on.

Every single RBF driver contains code to do something like the following
in its READ routine:

1. Set up the hardware and read the data.
2. Were we reading LSN0?  No, then exit.
3. Copy DD.SIZ bytes from PD.BUF to the drive table for the drive, then
return.

#3 is required by RBF, results in the same action in every driver, and
is not hardware-specific.  Upon returning from that READ, why does RBF
not simply copy the data itself?  What is the reason behind having the
driver do it?  You state that OS-9 is designed from the general to the
specific, and yet this is a violation of that principle: the GENERIC
function of updating the drive table is delegated to the SPECIFIC
drivers.  

I'm not saying it was WRONG, or it was not a necessary deviation; the
guys who designed OS-9 were sharp.  But I suspect the reason is no
longer valid, and we can remove this blight on the modular structure.

C.