Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: phys(2) under sVr3?
Message-ID: <11921@mimsy.UUCP>
Date: 11 Jun 88 10:18:18 GMT
References: <16090@brl-adm.ARPA> <48300009@hcx3>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 34

>From: Andrew Klossner <andrew@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@hcx3> gwp@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@mimsy.umd.edu	Path:	uunet!mimsy!chris