Date: Sun, 22 Mar 1998 09:44:36 -0500 From: Randall Hopper <rhh@ct.picker.com> To: Bruce Evans <bde@zeta.org.au>, Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>, Amancio Hasty <hasty@rah.star-gate.com> Cc: multimedia@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Fxtv vs Stable Message-ID: <19980322094436.65505@ct.picker.com> In-Reply-To: <199803220221.NAA18775@godzilla.zeta.org.au>; from Bruce Evans on Sun, Mar 22, 1998 at 01:21:39PM %2B1100 References: <199803220221.NAA18775@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Joao Carlos Mendes Luis: |#define quoting(Randall Hopper) |// 1) Comment out the "|PROT_WRITE" in: |// |// c->drv_buf = (TV_UINT8 *) mmap( (caddr_t)0, MAX_MMAP_BUF_SIZE, |// PROT_READ|PROT_WRITE, 0, c->fd, (off_t)0 ); | |Well, if you intend to mmap with PROT_WRITE, why do you open the device |with O_RDONLY ? :) Capture buffer access was originally read-only. When I needed to clear the buffer, I only had to add write on the mmap. I forgot about the open(), and the kernel was fine with the old, so it never got changed. Conceptually, I guess mmap() access now overrides open(). Though like you, seems to me mmap() allowable access probably should be a subset, for read & write at least. Maybe that should apply to PROT_EXEC as well. Thoughts? Wouldn't this also obviate the need for having any special mmap() IS-ROOT? checks for PROT_WRITE access? It does seem a little odd that an app can write to an mmaped buffer related to a device file they don't have write access to. At any rate, in this particular case we should pursue have the driver clear the buffer, so client apps only need to mmap PROT_READ/MAP_SHARED, and open the device O_RDONLY. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980322094436.65505>