From owner-freebsd-multimedia Sun Aug 17 19:46:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA14601 for multimedia-outgoing; Sun, 17 Aug 1997 19:46:10 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA14581; Sun, 17 Aug 1997 19:46:05 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id UAA09140; Sun, 17 Aug 1997 20:45:00 -0600 (MDT) Message-Id: <199708180245.UAA09140@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Michael Smith cc: terry@lambert.org (Terry Lambert), hasty@rah.star-gate.com, mestery@winternet.com, freebsd-multimedia@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Problem with my Wincast, fxtv In-reply-to: Your message of "Mon, 18 Aug 1997 10:39:57 +0930." <199708180109.KAA08329@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Aug 1997 20:45:00 -0600 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > Hmmm. If this is true, and it's intended *solely* as a QnD, > > then why net let him have his own isa_dmastatus()? It doesn't > > hurt anything, and it's not something that will live on in > > infamy. > ... > - Idealogically : there should not be a need for a private function > that screws with the DMA hardware. If the current feature set is > ... > time as "the" sound driver. As such, we're going to be looking at a > legacy condition sometime down the track where it is expected that the > sound driver be allowed to frotz with the DMA hardware, and that is I really don't want to get into this debate, but I think its important that people realize that the days of different pieces of code accessing common hardware are over. As SMP is brought into more and more of the kernel this becomes unacceptable. Areas such as the DMA hardware will have to be encapsolated into "critical regions". No one will be allowed to have private code to access these sorts of things, not even for short testing periods. A rather large part of my work in the coming days will involve finding such areas and eliminating them, please don't create any more! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD