miket@bnrmtv.UUCP (Michael Thompson) (04/11/89)
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! --/ | -----------------------------------------------------------------------------
jcm@mtunb.ATT.COM (was-John McMillan) (04/12/89)
In article <5221@bnrmtv.UUCP> miket@bnrmtv.UUCP (Michael Thompson) writes: >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. [yup] >I also am writing this device driver to answer another question several >people have brought up. [No you aren't: there is NO pending question... you are just pretending to be answering a question.] > 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 :-). [As previously posted: NMOUNT was compiled in as 4 -- unless you're running some b*stardized release (...of mine !-) This MAY be increased to 8 in next patch release.] ... >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. [Don't plan on loading many other drivers or running with less than 2 MB RAM. Anything over .5 MB is pushing your luck.] > 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? [Just one!-)] ... > 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. [Maybe two!-)] Your interest and activity are neat, but you need more assistance than can rationally be delivered here. Find sources for an existent driver [I'd recommend a "mem.c" first, then a disk driver] and study more. And learn your way about the /usr/include/sys/* files -- lotsa key info out there... like page sizes. The Upc is a good learning machine -- but a deeper understanding of the fundamentals is usually a prerequisite to starting a device driver. Start with a "/dev/kmem" clone, and work onwards. BTW: a "/dev/kmem" clone that supports HARDWARE-SPACE accesses may speed up your SCSI debugging anyway: unless there are time-out problems, you may be able to do much of your chip-exercising from USER-SPACE -- a REAL boom to quick turn-around. (Or system thudding, if mis-executed.) john mcmillan -- att!mtunb!jcm -- finite answers in infinite time