From owner-freebsd-hackers Tue Jan 23 13:40:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA19720 for hackers-outgoing; Tue, 23 Jan 1996 13:40:40 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA19707 for ; Tue, 23 Jan 1996 13:40:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18383; Tue, 23 Jan 1996 14:31:03 -0700 From: Terry Lambert Message-Id: <199601232131.OAA18383@phaeton.artisoft.com> Subject: Re: Amancio's tv program with capture! To: james@miller.cs.uwm.edu (Jim Lowe) Date: Tue, 23 Jan 1996 14:31:03 -0700 (MST) Cc: terry@lambert.org, dufault@hda.com, hackers@FreeBSD.org, hasty@rah.star-gate.com, jkh@time.cdrom.com, luigi@labinfo.iet.unipi.it, multimedia@rah.star-gate.com In-Reply-To: <199601232053.OAA14413@miller.cs.uwm.edu> from "Jim Lowe" at Jan 23, 96 02:53:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > How does one mark the driver/mmapped memory as shared memory > > > with the current utilities? It isn't real obvious that one can > > > actually do this without modifiying the shmat system call (or at > > > least to me). [ ... ] > > mapaddr = mmap( 0, /* map here, 0 = don't care*/ > > DEV_MEM_SIZE, /* device memory window*/ > > PROT_READ|PROT_WRITE, /* will be reading/writing*/ > > MAP_HASSEMAPHORE, /* (?) prevent caching*/ > > fd, /* fd for device*/ > > (off_t)0 /* full window*/ > > ); > > I know how to mmap. The question is once you have mapaddr how does > one attach that to X's shared memory functions through the Xshm > utilities? I don't beleive I have ever head of map_hassemaphore... I guess I don't understand the question. The device memeory is mapped at the first available location in the example above. You could cause it to be mapped anywhere you wanted (on a page boundry) give a non-zero first argument. All mmap() does in this case is establish a mapping for non-relocatable physical paged in the user process at the logical relative address requested (or, as in this example, the first available). The MAP_HASSEMAPHORE gives certain atomicity guarantess, which are generally implemented by disallowing caching and internally serializing page access... it was my way of suggesting that normal buffers should not be associated with the memory, and that it should be treated as direct access to ensure modifications are immediately reflected. See the mmap man page for details. What is it you want, and what does any of this have to do with Xshm? If anything, an X implemented on such a device layering and mapping facility would have an API mechanism to get at the memory area instead of using IPC to a DDX facility... that is, we are talking about mapping in the server, not in the client. For client mapping, the standard API would have to be used in situ and applied against the driver rather than a region exported by the server. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.