Xref: utzoo unix-pc.bugs:91 comp.sys.att:6937 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!rayssd!icus!lenny From: lenny@icus.islp.ny.us (Lenny Tropiano) Newsgroups: unix-pc.bugs,comp.sys.att Subject: Loadable "block" device drivers on the UNIX pc DON'T WORK! Keywords: block, /etc/lddrv/lddrv, /etc/masterupd, disk, SCSI Message-ID: <736@icus.islp.ny.us> Date: 9 Jul 89 17:51:29 GMT Organization: ICUS Software Systems, Islip, New York Lines: 108 Well I've been dabbling a little in device drivers lately, and my current quest is to see if I could write a block device driver. Using my copy of the blocks _Writing_a_UNIX_Device_Driver_ by Janet I. Egan and Thomas J. Teixeira, and their block driver example, I decided a good place to start would be their *working* driver. Although the book is specific to MASSCOMP's implementation of UNIX, RTU, the device-driver kernel routines were almost all identical to the UNIX pc's kernel routines. With that book, and my trusty photocopy of the "UNIX PC Version 3.0 Device Driver Development Guide, Issue 0" I was on my way ... First I started by typing in the 12 pages of code (to implement sort of a mini-ram disk), minus the comments for now ... Then I did the dreaded "cc -c" on the file. It had a few errors, undefined this, undefined that, typos, etc... I played around with the header files in /usr/include/sys, and got the appropriate changes (not much), and off I went to compile land. This time it compiled up! Ok, now I had to go hunting for Mike Ditto's vidram stuff, needed the simple INSTALL scripts he had. Found 'em! Modified the INSTALL scripts to install the block/character(for raw access) device and typed "./INSTALL". Off it went, installing the device into the /etc/master file with the commands ... /etc/masterupd -a block char init release open close ioctl read \ write strategy ram MAJ=`/etc/masterupd -b ram` /etc/mknod /dev/ram b $MAJ 0 MAJ=`/etc/masterupd -c ram` /etc/mknod /dev/rram c $MAJ 0 Then ... it did the /etc/lddrv/lddrv command to allocate and bind the driver. 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 ... Hmm, I thought. What did I do wrong? I wrote to Alex Crain (alex@umbc3.umbc.edu), who gave me some advice on where to look ... Basically the drvbind() kernel routine failed to bind the driver because of something... (he outlined 4 or so reasons why possibly). Nope, the driver looked OK. Then I spoke with Gil Kloepfer (gil@limbic.UUCP) one evening, and he was saying, "Can we do loadable block devices? Do they work?" All the devices we've used are character oriented. He suggested making a dummy driver with all function stubs. ram.c: raminit() { } ramrelease() { } ramopen() { } ramclose() { } ramioctl() { } ramstrategy() { } ramread() { } ramwrite() { } This compiled (of course) and then I tried the /etc/lddrv/lddrv -av ram command again... Sure enough it failed with the SAME ERROR! Hmm, I thought, the only block driver I know of is the disk driver, and that isn't loadable. (It's built into the kernel). Block Devices major device handler flags 0 disk gd ioctl write read close open pwr strategy fix char block required ... Hmmm, I thought to myself, I know I've seen somewhere you can do loadable block drivers (even though the UNIX PC Device Driver Development Guide is very vague when it comes to that... In the file /etc/master, it has this: ... * * Loadable drivers * nlbdrv number of slots for loadable block drivers * nlcdrv number of slots for loadable char drivers * nlbdrv NLBDRV 4 nlcdrv NLCDRV 10 Yes, 4 slots for loadable block drivers. Oh well, I'll forward this posting onto the person doing the work for the *next and last* FIXDISK for the UNIX PC. He's fixed everything so far, I'm sure he'll love to tackle this when he gets back from his trip :-) So to make a long story even longer, Mike Peterson who was trying the same thing and getting the same results ... now you know why. Those who tried to write SCSI device drivers (IDT) I wonder how they did it? Or if they did it at all, maybe that's why the SCSI board was abandoned ... Eventually when my driver is loaded I'll be able to do this ... # mkfs /dev/rram 200:10 # mount /dev/ram /ramdisk # df -t /ramdisk /ramdisk (/dev/ram ): 192 blocks 10 i-nodes total: 200 blocks 10 i-nodes Enough said ... -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930 lenny@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