From owner-freebsd-multimedia Sun Aug 17 18:13:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA08944 for multimedia-outgoing; Sun, 17 Aug 1997 18:13:47 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA08922; Sun, 17 Aug 1997 18:13:36 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA08329; Mon, 18 Aug 1997 10:39:58 +0930 (CST) From: Michael Smith Message-Id: <199708180109.KAA08329@genesis.atrad.adelaide.edu.au> Subject: Re: Problem with my Wincast, fxtv In-Reply-To: <199708180014.RAA11907@phaeton.artisoft.com> from Terry Lambert at "Aug 17, 97 05:14:43 pm" To: terry@lambert.org (Terry Lambert) Date: Mon, 18 Aug 1997 10:39:57 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, hasty@rah.star-gate.com, mestery@winternet.com, freebsd-multimedia@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > OTOH, general consensus > > is that Amancio's work is a QnD designed to get _something_ working > > now, so to me it makes little sense to try to track. > > 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. I was asking myself this in the shower this morning. Ultimately, there are three reasons that the idea reeks to me : - Idealogically : there should not be a need for a private function that screws with the DMA hardware. If the current feature set is broken, then that needs to be addressed. In this case, if Amancio and Luigi sit down and thrash out the issue together, I'm sure a sensible compromise will result. - Selfishly : having two separate functions is likely to raise more debugging/support work. - Pragmatically : it is likely the Amancio's code will (given that it works right now and nothing else comes close) spend quite a lot of 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 IMHO not a desirable position at all. > The issue of PnP (admittedly, he didn't raise that one in this > particular case, so it's kind of off-topic) is still hotly > debateable, I suppose (not something I'm going to debate late > on Sunday, though...). I'd prefer not to debate it either. I think that it's sufficiently separate that when the time comes it can be relocated without adversely affecting anything at all. I merely resent the effort that's being put into standalone PnP-for-sound-cards-only work where the same effort could be better spent on a generalised push. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[