Block device driver question?

[Michael Thompson]

Greetings everyone,

If I am going to write a SCSI device driver (or help someone else
write one) for the Unix PC, I have to learn about block device drivers
for the Unix OS.  So that I can get practice at writing a device driver
while waiting for more information about SCSI devices I have decided
to write a loadable device driver which will emulate a RAM disk of
about 64k bytes in size.  This device driver will then turn into the
prototype SCSI driver if I don't get any other existing code I can 
use.

I also am writing this device driver to answer another question several
people have brought up.  How many mountable devices can be placed in
the Unix PC mount table?  Some have thought that it may be as low
as 3 or 4 devices, but I am inclined to believe that many more devices can
be mounted just as with any other Unix kernel.  This is as long as
AT&T didn't do anything screwy with the mount table size :-).  What I
will do with my RAM drive device is format a lot of them as disk storage
and then mount them one at a time until I either run out of kernel memory
or reach a mount table limit.  Even though these are just small RAM disks,
they should have just as much kernel and mount table overhead as a 
multi-megabyte hard drive.  

The space my device driver will write into will be virtual memory obtained
through the vadalloc() call at init() time.  Is there a limit to how much 
virtual memory I can allocate?  I would like to vadalloc() upto 640k for
10 of these RAM disks.  This call wants to know what I want to allocate
in pages.  What is the size of a virtual memory page?  This memory will 
be manipulated with the standard block and character driver entry point
calls so I hope I can successfully emulate a diskdrive.  Does anyone see
any holes in my plans?  If you have a Unix PC driver that already emulates
a RAM disk, please send it to me.  It will save me several hours of 
scratching my head, but of course I know will learn more if I do it myself.
I know that this RAM disk emulator will be incredibly slow being in swap-
able virtual memory so don't write to tell me it will have no practicle 
value, just tell me if it will work or not.  

Now my last question regarding block device drivers.  I understand how a
Unix block device driver works in principle through the strategy entry 
point, but what about when trying to develop a driver which also implements
raw mode too.  The read and write entry points will be called with buffers
of data which may (most likely actually) not contain a full block of data,
but only a partial block.  Do I have to keep track of these partial buffers
or can I have the kernel do it through physck() and physio().  I am not 
clear on exactly how these two functions deal with random amounts of data 
in the buffers passed to them.  I hope that they can have the kernel
call my disk output/input functions when there is a full buffer to be written
or read.  I do not want to keep track of the number of bytes in a buffer 
before it is written out.  Do I ask for too much from the kernel?  It
sure would be nice if I only had to come up with read/write routines for
a full block of data and have the kernel worry about partial blocks. 

Perhaps someone can quickly send me a note which shows how my drv_read and
drv_write functions interact with the physck() and physio() calls and how
all of this relates to the drv_strat function.  The books and notes I have
just don't seem to make all of this clear.  Perhaps I have a thick skull.

Of course I will post this driver to the net once it is written so we can
all use it to learn from and use as a model for other drivers.  I will not
be responsible if it you use it and it crashes your Unix PC which causes
your computer to short circuit causing your local power grid in your
neighborhood to fail causing a black out all along the Eastern Seaboard
causing ... causing an end to society as we know it.  Hey, it could 
happen. :-)

Mike Thompson 
-----------------------------------------------------------------------------
			  |  Michael P. Thompson, Member Scientific Staff   |
		 ###      |  BNR/Northern Telcom, Dept. 4Z15                |
####  #####    #########  |  685A E. Middlefield Road                       |
############ ###########  |  Mountain View, CA  94039-7277                  |
####    ####    ####      |  PH. (415) 940-2575  FAX. (415) 966-1067        |
####    ####### ########  |        amdahl! --\                              |
####     #####   ######   |  UUCP. ames! ----->-- bnrmtv!miket              |
			  |        hplabs! --/                              |
-----------------------------------------------------------------------------