Date: Tue, 15 Jun 2004 15:18:34 -0600 From: Scott Long <scottl@freebsd.org> To: Gordon Tetlow <gordon@freebsd.org> Cc: Joseph Dunn <joseph@magnesium.net> Subject: Re: cvs commit: src/sys/dev/sound/pci emu10k1.c Message-ID: <40CF67AA.50600@freebsd.org> In-Reply-To: <20040615160107.GT10016@spiff.melthusia.org> References: <200406132212.i5DMC3b9075832@repoman.freebsd.org> <20040614011012.H1600@newtrinity.zeist.de> <20040614010854.GA98360@dragon.nuxi.com> <40CCFCDF.4040303@freebsd.org> <20040615160107.GT10016@spiff.melthusia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > -gordon It's fine to put an unknown ID into a driver to do local testing and discovery. It's less acceptable to commit that change to FreeBSD CVS without knowing what it does and what impact it has. Anyways, this has been kicked around enough and I believe that David already said that he will back out the change. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40CF67AA.50600>