andrew@frip.gwd.tek.com (Andrew Klossner) (06/01/88)
I need to augment sys V release 3 so as to let a user process map a
video frame buffer into its address space. Something like the version 7
phys(2) call, or what the 4.2BSD mmap(2) call promised but didn't
deliver, is what I'm looking for.
Surely I'm not the first to look at this. I'd be grateful for any
suggestions, design notes, experience-based comments, words of wisdom,
or (say it softly) working code that I can put into a proprietary,
for-profit product.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]heiby@mcdchg.UUCP (Ron Heiby) (06/04/88)
Motorola Microcomputer Division's System V/68 Release 3 has an augmentation to the shmget(2) call, whereby a process with euid 0 can specify the *physical* address at which the shared memory segment is to be located. said process can then set permissions, owner, and group appropriately for the application and exit, leaving the shared memory segment ready to be shmat(2)'d by the appropriate processes. I have a couple of customers who have used this interface to avoid writing a driver for (for example) an imaging board. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Failure is one of the basic Freedoms!" The Doctor (in Robots of Death)
preece%fang@xenurus.gould.com (Scott E. Preece) (06/06/88)
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. Something like the version 7 > phys(2) call, or what the 4.2BSD mmap(2) call promised but didn't > deliver, is what I'm looking for. ---------- In release 2.1 of Gould's UTX/32 (4.3 + System V emulation) we have added the ability to configure a system with specific areas of physical memory defined as special, so that the kernel will not allocate them for general use We call those areas extents. It is then possible, either in the system configuration file or by using a new system call, to create regions at specified offsets from the beginning of specified extents. When a region is created, a System V shared memory object is created as its handle. Jobs may then attach to that object to get access to the appropriate area of physical memory. We have also provided a way for jobs to request attachment to specified shared memory objects at exec time, using information stuffed into the COFF (well, COFF-like) header. Finally, we also added a second class of region for which "attachment" means allocating pages from the pool covered by the region. This allows handling areas of memory that have special characteristics (Gould systems can have cache-speed memory boards mixed with regular memory) but don't need contiguous allocation. -- scott preece gould/csd - urbana uucp: ihnp4!uiucuxc!urbsdc!preece arpa: preece@Gould.com
gwp@hcx3.SSD.HARRIS.COM (06/11/88)
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. Something like the version 7 > phys(2) call, or what the 4.2BSD mmap(2) call promised but didn't > deliver, is what I'm looking for. 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. User processes may then attach this chunk of physically-mapped virtual memory into their address space with the shmat(2) service. This sounds a bit complicated at first but I think it has several advantages over phys(2), mmap(2) et. al. The first is security/usability. Allowing users direct access to physical or I/O memory (for those architectures with memory mapped I/O) is _extremely_ _dangerous_ (imagine Joe user mapping the device controller registers for your root-partition disk into his address space). The usual solution to this is to make phys(2), mmap(2) etc. super-user only, which then causes everyone to write their applications suid-root thus voiding _all_ user protections. By binding a chunk of physical memory to a shared memory region you allow access to that chunk to be controlled through the user-group-other bits of the ipc_perm handle. Of course shmbind(2) must be restricted to super-user, but the objects it creates can be accessed by anyone you wish. Furthermore multiple processes can attach and detach the same chunk of physical memory in an simple and straightforward manner without creating multiple regions or sets of page tables. The second advantage is one of consistency (at least for Sys V types). There already exists a system service for adding a chunk of virtual memory to a users address space. That service is "shmat(2)". Why should there be another service that does pretty much the same thing, except that the chunk of virtual memory is now associated with a specific range of physical memory ? Why not create a service that performs this later operation, and then leave the rest to shmat(2) ? The interface to shmbind(1) as I have written it is: int shmbind(int shmid, caddr_t p_addr) Shmid is the id returned from shmget(2) and p_addr is the starting physical address of the chunk you wish to map. The size of the physical chunk mapped is the size of the shared memory region you arre mapping it into (the "size" argument to the shmget(2) call). The physical addresses can lie in either "normal" RAM-space or in I/O memory space (our machines use memory-mapped I/O). If the requested physical memory lies in RAM-space the system will attempt to allocate the appropriate pages at shmbind(2) time. If the desired pages of physical memory are already allocated the shmbind(2) service returns the ENOMEM error. Bind operations involving I/O memory are always honored since I/O memory "pages" are not a critical resource (they're really "ghost pages" consisting of page table entries pointing to I/O locations). It is possible to reserve sections of RAM-memory for later binding by placing "reserve" entries in the config file and rebuilding the kernel. I've also have a utility called shmconfig(1) (with more options than you probably care about) that performs the shmget(2), shmbind(2), and shmctl(2) operations necessary to create a physically-bound shared memory region with the desired user, group and permission bits. This utility is primarily for use in /etc/rc so that you can configure a system with the desired "mappable objects" already present at init time. What do you think ? Gil Pilz -=|=- Harris Computer Systems -=|=- gwp@ssd.harris.com
chris@mimsy.UUCP (Chris Torek) (06/11/88)
>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
randy@umn-cs.cs.umn.edu (Randy Orrison) (06/11/88)
In article <11921@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: |>The second advantage is one of consistency (at least for Sys V types). |Of course, mmap is consistent under SunOS (and someday 4BSD). and someday SysVR4? Come on, AT&T&SUN, you can do it! |If you are stuck with System V's `new and wretched namespace'[*] |for memory regions, shmbind() is probably appropriate. Now if only they would fix this, too! Me, I have great hopes... |[*]An approximate quote from Dennis Ritchie, I think. |In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) -randy -- Randy Orrison, Control Data, Arden Hills, MN randy@ux.acss.umn.edu 8-(OSF/Mumblix: Just say NO!)-8 {ihnp4, seismo!rutgers, sun}!umn-cs!randy "I consulted all the sages I could find in Yellow Pages, but there aren't many of them." -APP