Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!bullwinkle!rochester!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: phys(2) and accessing physical memory
Message-ID: <2632@umcp-cs.UUCP>
Date: Mon, 23-Dec-85 20:20:24 EST
Article-I.D.: umcp-cs.2632
Posted: Mon Dec 23 20:20:24 1985
Date-Received: Wed, 25-Dec-85 03:11:48 EST
References: <270@moncskermit.oz> <177@daab.UUCP> <612@unisoft.UUCP> <135@hadron.UUCP> <264@twitch.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 24

In article <264@twitch.UUCP> grt@twitch.UUCP (G.R.Tomasevich) writes:

> My suggestion about reading from /dev/mem and calculating the
> address is trivial only if the physical address space is commensurate
> with the number of address bits in the DMA device,

And if the device does not need byte transfers or something
else exotic, and if on a Vax, can tolerate longword transfers
(as opposed to word transfers; see /dev/kUmem).

> If you need to access something like a Unibus map, for example,
> it would be a pain from user space.

kUmem in 4BSD does not go through the Unibus maps for you; it is
just kmem with word transfers.  This is necessary anyway on Vaxen
since there can be multiple UBAs.

On Vaxen, kmem is easier to use than mem, since you need not look
up all the page tables.  As long as the object of your search is
in system space, you are OK.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu