From owner-freebsd-multimedia  Fri Mar 21 13:37:47 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA14934
          for multimedia-outgoing; Fri, 21 Mar 1997 13:37:47 -0800 (PST)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA14929
          for <multimedia@freebsd.org>; Fri, 21 Mar 1997 13:37:44 -0800 (PST)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id NAA01992; Fri, 21 Mar 1997 13:37:26 -0800 (PST)
Message-Id: <199703212137.NAA01992@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Louis A. Mamakos" <louie@TransSys.COM>
cc: Steve Passe <smp@csn.net>, Michael Petry <petry@netwolf.NetMasters.com>,
        multimedia@freebsd.org
Subject: Re: Continquous Memory vs Virtual Memory 
In-reply-to: Your message of "Fri, 21 Mar 1997 16:00:04 EST."
             <199703212100.QAA08668@whizzo.transsys.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 21 Mar 1997 13:37:26 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


The trick is to come up with a way that anyone can use it .
If you will a "Risc compiler" in the driver in which the user
passes a given "program" which then gets translated by the driver
to an actual "risc program" is probably the way to go and not the
way that bttv has implemented building "risc" programs.

The current "risc" programs in the bt848 driver makes it difficult for
people to screw up their systems . Granted , the PCI to PCI scheme
still leaves a nice way for someone to pass an illegal address;however,
given that there is a nice way for an application to get the physical
address of a PCI video cars' frame buffer, the existing risk is acceptable.

Louis, idea of passing a clip-list to the driver is a good starting
point.

Any Takers for a cool Bt848 translator, or implementing a clip-list
at the driver ?

For whatever is worth , now is a good time to start thinking of 
increasing the complexity in the bt848 driver -- in other words
the driver is sufficiently stable .

	Enjoy,
	Amancio

>From The Desk Of "Louis A. Mamakos" :
> While we're making the software which builds the channel programs, er, 
> RISC programs most complicated, we could add in support for user specified
> clipping regions.  I think there's some code which could be swiped from
> the bttv program which does some of that.  As it is, the bttv program
> computes the RISC program in user space, and then shoves it into the
> kernel; this seems like the wrong division of labor and makes it more
> difficult to control what memory gets stomped on.   You wouldn't want
> a video capture pointed at the effective UID field of the "u" area,
> would you?
> 
> louie
>