Xref: utzoo comp.sys.att:6085 unix-pc.general:2645 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!bnrmtv!miket From: miket@bnrmtv.UUCP (Michael Thompson) Newsgroups: comp.sys.att,unix-pc.general Subject: Block device driver question? Keywords: Device Driver Unix PC 3B1 7300 Message-ID: <5221@bnrmtv.UUCP> Date: 10 Apr 89 22:37:50 GMT Organization: Bell Northern Research, Mtn. View, CA Lines: 76 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! --/ | -----------------------------------------------------------------------------