From owner-cvs-all@FreeBSD.ORG Tue Jun 15 21:00:39 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8720D16A4D2; Tue, 15 Jun 2004 21:00:39 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79DC043D2D; Tue, 15 Jun 2004 21:00:39 +0000 (GMT) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 518AF881B; Tue, 15 Jun 2004 14:00:35 -0700 (PDT) From: Peter Wemm To: Gordon Tetlow Date: Tue, 15 Jun 2004 14:00:35 -0700 User-Agent: KMail/1.6.1 References: <200406132212.i5DMC3b9075832@repoman.freebsd.org> <40CCFCDF.4040303@freebsd.org> <20040615160107.GT10016@spiff.melthusia.org> In-Reply-To: <20040615160107.GT10016@spiff.melthusia.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406151400.35010.peter@wemm.org> cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: Scott Long cc: obrien@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Joseph Dunn Subject: Re: cvs commit: src/sys/dev/sound/pci emu10k1.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 21:00:39 -0000 On Tuesday 15 June 2004 09:01 am, Gordon Tetlow wrote: > On Sun, Jun 13, 2004 at 07:18:23PM -0600, Scott Long wrote: > > >Possibly. Still doesn't mean we shouldn't add the PCI ID to help > > > people farther along in determining if it really works or not. > > > If we get reliable failure reports in 5-CURRENT (which has a much > > > updated driver from 5.2.1) we can print out an error message in > > > the probe. > > > > Well, this is kinda like finding a new Adaptec ID and adding it to > > the ahc driver just because it's there, regardless of whether the > > driver can talk to the chip. > > I would also argue that storage subsystems and sound cards are two > very different class of devices. We can afford to be a little > overzealous with sound hardware. If it doesn't work, it's not the end > of the world. If a storage subsystem that is probed doesn't work (or > worse, silently fails in subtle ways), that's much worse. Yes, and also the mode of failure is significant. If the probe/attach fails with messy errors, that is far preferable to the machine hanging in the driver. Do we know what happens as a result of the id's that David added? > -gordon -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5