From owner-freebsd-current@FreeBSD.ORG Mon Feb 27 12:13:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D011016A425; Mon, 27 Feb 2006 12:13:44 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F4A43D72; Mon, 27 Feb 2006 12:13:38 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id k1RCD8jC033730; Mon, 27 Feb 2006 15:13:08 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id k1RCD5nO033728; Mon, 27 Feb 2006 15:13:05 +0300 (MSK) (envelope-from yar) Date: Mon, 27 Feb 2006 15:13:05 +0300 From: Yar Tikhiy To: Coleman Kane Message-ID: <20060227121305.GO6435@comp.chem.msu.su> References: <20060225140509.GC79616@comp.chem.msu.su> <44008314.8030205@samsco.org> <20060225201102.GA6936@pint.candc.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060225201102.GA6936@pint.candc.home> User-Agent: Mutt/1.5.9i Cc: current@freebsd.org, cokane@freebsd.org Subject: Re: RFC: separate 3dfx_linux module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 12:13:45 -0000 On Sat, Feb 25, 2006 at 03:11:02PM -0500, Coleman Kane wrote: > I have unfortunately lost all of my voodoo hardware. > > On Sat, Feb 25, 2006 at 09:17:24AM -0700, Scott Long wrote: > > Yar Tikhiy wrote: > > >Hi there, > > > > > >In the course of reviewing and cleaning up the default configuration > > >of kernel options, it was suggested by the Release Engineers that > > >we had a separate module for TDFX_LINUX instead of placing the > > >burden on the device tdfx and module 3dfx. Could anybody interested > > >test this change? I've made sure it builds, but I have no 3dfx hw > > >to really test it. The testing is as simple as building the new > > >3dfx and 3dfx_linux modules, loading them, and verifying that the > > >linux apps work with the device as before. Thanks in advance! > > > > > Sounds goo to me. I am all for further modularization of the codebase. Thanks! > > Why keep the TDFX_LINUX option defined in sys/conf/options? > > Sounds good to me. In the event that you want to build this statically > into the kernel, doesn't the option still need to be available, > or are we talking about a device tdfxlinux ? It was exactly my point, too: the TDFX_LINUX option has to be there so that people still can compile device tdfx with Linux support into the main kernel file. -- Yar