Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hadron.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!gatech!ut-sally!seismo!rlgvax!hadron!jsdy
From: jsdy@hadron.UUCP (Joseph S. D. Yao)
Newsgroups: net.unix-wizards
Subject: Re: Need help in accessing physical address in Unix
Message-ID: <117@hadron.UUCP>
Date: Tue, 3-Dec-85 01:29:28 EST
Article-I.D.: hadron.117
Posted: Tue Dec  3 01:29:28 1985
Date-Received: Thu, 5-Dec-85 08:12:19 EST
References: <270@moncskermit.oz>
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Lines: 45
Keywords: physical memory address

In article <270@moncskermit.oz> cheung@moncskermit.oz (Lawrence Cheung) writes:
>we intend to put the frame grabber in the physical memory map and
>access the frame grabber through its PHYSICAL ADDRESS, ...
>1) Can we access a physical address directly in UNIX without using a 
>   device driver?

Hard to answer.  To access anything in UNIX, you have to use some
kind of code, which can be construed as a device driver.  If you
are asking, can you access it directly without the overhead of
indexing through the device driver table, then you can use a
separate system call; and if you want to avoid that overhead, then
you will have to map the memory pages into your process's address
space, which can be done, but ...  You probably will want your
"open" routine (Oh, here we are in a driver again) to lock the frame
buffer from other access, put your process close to the kernel in
physical memory (to reduce fragmentation), lock it against swapping
or paging, and then modify your segment addresses so that the buffer
is in your address space, when you are scheduled to run.  You will
have to make sure that the "close" routine undoes all this.  Just
to be safe, you should make sure that the scheduler and swapper/
pager are happy with pages that shouldn't be touched in your address
space.  And there are probably a few other things I've forgotten off
the top of my head.

>2) Can we have fast access to the frame grabber using other means?

You could also set up kernel routines that will double- (or n-)buffer
frames for you and pass them back.  This can be done with n buffers
in the kernel, passed back via a copyout() on demand, which may lose
data if you are trying an N-per-second grab.  This can also be done
with buffers that your user program provides.  In this case, the
program must again be locked against swapping and paging (at least
the buffers must); and you will have to provide some sort of signalling
mechanism to let the user program know when a buffer is filled.

Incidentally, all of these techniques require additions to kernel
code that may be considered "driver" code:  classic read, direct
access via system call, asynchronous read, mapped memory; and each
of these can be set up for read on demand or n-buffered storage.
I don't know what extra hooks the National VR32 might or might not
have; but any of these techniques on baseline VAX sVr2 would require
kernel mods (if only just the addition of the driver).
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}