From owner-freebsd-hackers Tue Jan 23 10:11:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA07105 for hackers-outgoing; Tue, 23 Jan 1996 10:11:59 -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 KAA07100 for ; Tue, 23 Jan 1996 10:11:57 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA17864; Tue, 23 Jan 1996 10:55:29 -0700 From: Terry Lambert Message-Id: <199601231755.KAA17864@phaeton.artisoft.com> Subject: Re: Amancio's tv program with capture! To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 23 Jan 1996 10:55:29 -0700 (MST) Cc: dufault@hda.com, jkh@time.cdrom.com, hasty@rah.star-gate.com, multimedia@rah.star-gate.com, hackers@FreeBSD.org In-Reply-To: <199601231226.NAA07338@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jan 23, 96 01:26:06 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 > 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. [ ... ] > 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. I would suggest adding an mmap() entry point for the device driver and calling it when you request pages to be mmapped. The system mmap() interface would not be changed, it would just act differently for vnodes that were devices. This would work for mapping video memory by device generically as well as frame capture buffers, etc.. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.