From owner-freebsd-multimedia  Tue Nov  4 01:57:28 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA29810
          for multimedia-outgoing; Tue, 4 Nov 1997 01:57:28 -0800 (PST)
          (envelope-from owner-freebsd-multimedia)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA29794
          for <multimedia@FreeBSD.ORG>; Tue, 4 Nov 1997 01:57:01 -0800 (PST)
          (envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA19627; Tue, 4 Nov 1997 09:43:11 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199711040843.JAA19627@labinfo.iet.unipi.it>
Subject: Re: A small addition to the bt848 driver...
To: hasty@rah.star-gate.com (Amancio Hasty)
Date: Tue, 4 Nov 1997 09:43:10 +0100 (MET)
Cc: multimedia@FreeBSD.ORG
In-Reply-To: <199711040831.AAA00548@rah.star-gate.com> from "Amancio Hasty" at Nov 4, 97 00:31:00 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > > Passing whatever address you want to the bt848 is not a security 
> > > hole if people are so concerned about it then just add appropiate
> > > permissions to /dev/bktr* .
> > 
> > precisely my point (however maybe something could be done in the
> > driver to check at least that the "video.addr" does not point to
> > pages of non-video RAM).
> 
> Nope I rather keep this way for the purpose of future usage like dumping
> video straight to a memory mapped region of a device other than
> a video card.

ok so let's keep it like this.

> > > Typically Luigi, if it is for development the code is wrapped around
> > > a #ifdef ;however, if you feel like you have a genuine usage for
> > > your ioctl then I will be happy to have them committed.
> > 
> > whatever you like. I think this will let us write user-space apps to
> > control the tuner, teletext circuitry and so on. This can be a
> > significant advantage even for non-developers who will not have to
> > rebuild the kernel to upgrade.
> > 
> 
> Fine then please just check in the code for controlling the tuner.

not ready yet (and that would be teletext, not tuner!) unless you
mean the few lines that implement the ioctl() and the message is
directed to mark murray :)

	Cheers
	Luigi