phys(2) under sVr3?

[Chris Torek]

>From: Andrew Klossner <andrew at frip.gwd.tek.com>
>>I need to augment sys V release 3 so as to let a user process map a
>>video frame buffer into its address space.

[note that Sun does this with mmap() in SunOS 2.x and 3.x, albeit a
bit clumsily, and with mmap() in SunOS 4.0 quite elegantly.]

In article <48300009 at hcx3> gwp at hcx3.SSD.HARRIS.COM writes:
>I went around and around with this problem and finally came up with
>something called shmbind(2).  This system service takes an existing
>shared memory region (created via shmget(2)) and binds a chunk of
>physical memory to that region. ... [This] has several advantages
>over phys(2), mmap(2) et. al.
>
>The first is security/usability. ... [usually] mmap(2) etc. [are]
>super-user only, which then causes everyone to write their
>applications suid-root thus voiding _all_ user protections.

mmap() is not restricted to super-user.  Anyone may call mmap;
but to map a device address, you must first open the device, then
pass any protection checks in the device driver.  Hence the file
system provides the appropriate security (via user/group/other),
and specific devices can be further restricted if appropriate.

>The second advantage is one of consistency (at least for Sys V types).

Of course, mmap is consistent under SunOS (and someday 4BSD).

If you are stuck with System V's `new and wretched namespace'[*]
for memory regions, shmbind() is probably appropriate.

[*]An approximate quote from Dennis Ritchie, I think.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris