Xref: utzoo comp.sys.att:6087 unix-pc.general:2648
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!rutgers!att!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Block device driver question?
Summary: Whoaaa Nellie!!!
Message-ID: <1467@mtunb.ATT.COM>
Date: 11 Apr 89 17:02:15 GMT
References: <5221@bnrmtv.UUCP>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 67

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