beaucham@uiucuxc.UUCP (04/28/84)
#N:uiucuxc:29300011:000:347
uiucuxc!beaucham Apr 28 22:52:00 1984
Can someone refer me to a standard syscall (in version 7, 4.1) which
will allow special users to read/write from/to memory which the unix
system prevents normal users from using? apparently this is used in
bitmapped memory graphics applications.
jim beauchamp allegra!harpo!uiucdcs!uiucuxc!beaucham
or pur-ee!/gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/04/84)
Try the PHYS(2) system call (7th Edition UNIX only). It lets you clobber anywhere in memory.
jab@uokvax.UUCP (05/06/84)
#R:uiucuxc:29300011:uokvax:6100031:000:913
uokvax!jab May 6 12:41:00 1984
On the v7 systems, there was a "research" system call called "phys()" that
allowed you to poke things into your pdp-11 segmentation registers. You
could, for example, map the I/O page into your address space and output
to the console by polling the DL11/KL11 that talks to the console terminal.
One person I know used it every once in a while as a glorified way to patch
tty structures that were wedged because of some weird dh11 code.
It's not on system {III,V}, and not in anything on a vax, because it's
terribly machine-dependent and unless you have something that looks like
old-fashioned segments, amazing things can happen. I can imagine what happens
if you try to talk to something in a Unibus space on a vax and it's not there...
(It's not polite enough to bomb your process off with a segmentation violation,
like on the 11, but instead will probably croak the kernel itself.)
Jeff Bowles
Lisle, ILmats@dual.UUCP (Mats Wichmann) (05/06/84)
Phys(2) is a lovely way to step on yourself. When we had a floating-
point processor board added to our system, a phys() call went into
the floating-point support library which mapped the board into an
`appropriate' memory address. This `appropriate' address was picked
right up by one of our compiler vendors. Current revisions of our kernel
have UEND defined to a different value, since that phys() call happened
to map the I/O addresses for the board into the middle of the stack......
Anyway, phys() is a VERY hardware-dependant piece of code, which
probably explians why it is found in so few `standard' releases.
I would guess that most micro-UNIX vendors provide something like
phys (UniSoft implements it for all of their ports, V7, Sys III, Sys V, etc),
because in the micro world it is considered more appropriate to be
able to talk directly to specific pieces of hardware not supported by
device drivers. I guess it beats adding peek() and poke() to C.....
Sigh.....
Mats Wichmann
Dual Systems Corp.
...{ucbvax,amd70,ihnp4,cbosgd,decwrl,fortune}!dual!matsjdb@mordor.UUCP (05/07/84)
"phys" is certainly a great way to step on yourself. But then, the one time that I used it, that was precisely what I intended to do. I wanted a program which could reboot my V7 PDP-11/45 (and other local PDP-11's) without tying up kernel I-space. (I was very protective of the kernel in those days; I would be today, but on 4.2BSD it seems hopeless.) My program just read a disc block, did an spl7(), copied it to physical location zero, blew away memory management (and everything else) with a "reset", and jumped to zero. BLAMMO -- reboot! Aside from something as inherently machine-dependent as this reboot program, I was very nervous about programs which referenced memory directly (or through "/dev/mem"). There are just too many ways to make mistakes, and UNIX is not very forgiving of accidentally trashed memory. (Nor are other users when you cause the machine to crash.) -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb
wapd@houxj.UUCP (Bill Dietrich) (05/07/84)
Maybe I'm missing something, but I thought that /dev/mem was there for exactly this purpose. You need super-user permissions, of course. Bill Dietrich houxj!wapd