[Coco] RBF and LSN0

[Robert Gault]

Chuck Youse wrote:
> So I've written two RBF drivers in recent weeks, and a thought has a
> occurred to me, and I'm wondering if anyone can shed light on this.  If
> Boisy is lurking he's probably the guy with the answer.
> 
> So RBF drivers are required to update their drive tables with the LSN0
> "superblock" information every time that LSN0 is read; this is so that
> RBF can consult the drive table to find out useful filesystem
> information, like the size in sectors, etc.  So every RBF driver is
> required to take a special action on reading LSN 0, and perform
> essentially the same task.
> 
> It seems like a lot of duplication of code.  RBF knows when it's reading
> LSN0, and it knows where the drive tables are kept in the driver's
> static data area; so why is this functionality pushed off to the driver?
> It seems RBF has all the information required to do this itself.. it's
> RBF-specific information, anyway -- if you're using a different file
> manager, this action is probably superfluous.
> 
> So anyone know why this was designed this way?
> 
> C.
> 

  The design of OS-9 is to start with the general and move towards the 
specific. If implemented correctly, this would produce very efficient 
code, perhaps the most efficient code.
  So managers, Random Block File manager as an example, are charged with 
handling I/O buffers and data flow on random access devices but not the 
details of the physical characteristics of any specific device. Since 
many kinds of random access devices are possible, the actual 
communication is left to drivers.
  For a driver to talk to a specific type of device capable of several 
different formats, ex. a floppy disk, the specific format is stored in 
LSN0. This is read once per device access and does not need to be read 
again as long as the path is kept open.

  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.
  If it were found that there was duplicate code in several/many 
drivers, it would indicate that either the drivers were not well written 
or that a new level of intermediate manager should be designed. That's 
why there are more levels of managers in the data flow to a Window than 
there are to a Disk.