Loadable "block" device drivers on the UNIX pc DON'T WORK!
Lenny Tropiano
lenny at icus.islp.ny.us
Tue Jul 11 09:26:22 AEST 1989
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
More information about the Unix-pc.bugs
mailing list