Loadable "block" device drivers on the UNIX pc DON'T WORK!

[Lenny Tropiano]

In article <736 at icus.islp.ny.us> lenny at icus.islp.ny.us (Lenny Tropiano) writes:
|>
...
|>cp ram.o /etc/lddrv
|>/etc/lddrv/lddrv -av ram
|>allocated: 0x4000 bytes starting at 0x5c000 for device ram, B:10 C:9 id:4
|>BIND failed: invalid argument
|>
|>...

Problem has been solved.  A very kind person from AT&T gave me a call
today at my office, and told me that he had similar results when he tried
block devices on the UNIX pc.  What he said was that the drvbind()
kernel routine requires the presence of *strategy() and *print() routine,
even if they don't do a darn thing...  In my case they would be called 
ramstrategy() and ramprint() respectively.

Sure enough I tried this and the driver loaded and bound itself to
the kernel space.  Now it is time to remove the bugs from the driver ;-)

BTW: According to the _UNIX PC Device Driver Development Guide_, 
print() routines (and I quote) ...

*  Print

   This entry point is for the error reporting routine of the driver.
   It is most often left unused, and is not used at all in the present
   UNIX PC kernel.   It may be here for historic reasons.


Obviously if this isn't used at all ... I still consider it a bug that
drvbind() requires it.   Oh well, if it can't be fixed at the present,
this will do.

ramprint()
{
	panic("Ut oh!  I'm in ramprint(), how did I manage this?");
}

-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 589-7930
lenny at icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{ames,talcott,decuac,hombre,pacbell,sbcs}!icus!lenny     attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752