Date: Tue, 23 Jan 1996 13:26:06 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: dufault@hda.com (Peter Dufault) Cc: jkh@time.cdrom.com, hasty@rah.star-gate.com, multimedia@rah.star-gate.com, hackers@freebsd.org Subject: Re: Amancio's tv program with capture! Message-ID: <199601231226.NAA07338@labinfo.iet.unipi.it> In-Reply-To: <199601231108.GAA14059@hda.com> from "Peter Dufault" at Jan 23, 96 06:08:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
[background]
we were discussing the possibility of making a shared memory segment
use the physical pages where the frame grabber dumps its output. The
frame grabber has an mmap() call to give the user program access to
these data.
----
Luigi:
> > > Note that it should be possible in principle, it's just that there
> > > isn't any parameter that you can specify to do that. Perhaps some of
> > > our -hackers or XFree people know how to do this.
> >
Jordan:
> > It would be hard. You'd basically have to figure out what the fixed
> > address corresponding to the meteor's frame buffer was and cause the
> > shared memory segment to map the same region of memory. It definitely
> > doesn't look to be possible with any of the standard system calls.
>
Peter:
> I shouldn't jump in when I know nothing, but can you
> add an mmap to the frame buffer driver and then map it to the shared
> segment, or have everyone that wants to use it then map it in?
terminology: "frame buffer" is usually the name of the output buffer,
while the meteor is an input device.
In any case, the meteor has an mmap() call.
I was looking at shmat():
shmat(int shmid, void *addr, int flag)
DESCRIPTION
Shmat() attaches the shared memory segment identifed by shmid to the
calling process's address space. The address where the segment is at-
tached is determined as follows:
...
o If addr is nonzero and SHM_RND is not specifed in flag, the segment
is attached the specified address.
...
thus, in principle, you could pass the parameter to the kernel.
A possible implementation could delay the actual allocation of pages to
the time shmat() is called the first time, as opposed to what I believe
is the current behaviour of allocating pages in shmget().
At this point, if the virtual address is already mapped, and provided
the shm segment is not already mapped, use the existing pages to
map the memory. My guess is that the current code would fail in this
case.
Unfortunately I think this would require non-trivial changes to the
code in sysv_shm.c, and might possibly have some side effects.
I am cross-posting this to hackers for advice.
Luigi
====================================================================
Luigi Rizzo Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it Universita' di Pisa
tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522 http://www.iet.unipi.it/~luigi/
====================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601231226.NAA07338>