Date: Tue, 23 Jan 1996 14:31:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: james@miller.cs.uwm.edu (Jim Lowe) 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 Subject: Re: Amancio's tv program with capture! Message-ID: <199601232131.OAA18383@phaeton.artisoft.com> In-Reply-To: <199601232053.OAA14413@miller.cs.uwm.edu> from "Jim Lowe" at Jan 23, 96 02:53:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601232131.OAA18383>