From owner-freebsd-hackers Tue Jan 23 04:36:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA11049 for hackers-outgoing; Tue, 23 Jan 1996 04:36:04 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA10867 for ; Tue, 23 Jan 1996 04:34:32 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA07338; Tue, 23 Jan 1996 13:26:07 +0100 From: Luigi Rizzo Message-Id: <199601231226.NAA07338@labinfo.iet.unipi.it> Subject: Re: Amancio's tv program with capture! To: dufault@hda.com (Peter Dufault) Date: Tue, 23 Jan 1996 13:26:06 +0100 (MET) Cc: jkh@time.cdrom.com, hasty@rah.star-gate.com, multimedia@rah.star-gate.com, hackers@freebsd.org In-Reply-To: <199601231108.GAA14059@hda.com> from "Peter Dufault" at Jan 23, 96 06:08:30 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk [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/ ====================================================================