From owner-svn-src-all@FreeBSD.ORG Mon Jan 19 16:35:26 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6871065688; Mon, 19 Jan 2009 16:35:26 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id ACD728FC26; Mon, 19 Jan 2009 16:35:25 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n0JGZOaE059006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 08:35:25 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4974ABCC.7000107@freebsd.org> Date: Mon, 19 Jan 2009 08:35:24 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Maxim Sobolev References: <200901190710.n0J7ACSg001385@svn.freebsd.org> <497432A1.9060805@samsco.org> <497446D4.5020104@FreeBSD.org> In-Reply-To: <497446D4.5020104@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r187426 - head/sys/amd64/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 16:35:29 -0000 Maxim Sobolev wrote: > Scott Long wrote: >> prepare to be wrong. And above all else, don't put drivers into here >> that you haven't tested. It's pretty silly to admit in your commit >> message, for all to see, that you are blatantly committing without >> testing. > > Actually this is interesting point, what the best strategy for us as > the project should be? Should we new put drivers that have been tested > on i386 only and don't have any particular reason to be i386-specific > (i.e. ISA/EISA drivers, PCMCIA drivers etc) into amd64 GENERIC > automatically and wait for somebody to report a problem, or stay on > the safe side and enable drivers on amd64 only after somebody actually > has tested them and confirms that they are working? Should this policy > depend on driver class (for example a storage driver has much higher > potential for screwing user's data compared to a network driver or a > sound driver) and on release (HEAD / STABLE)? IMHO FreeBSD could > benefit by putting at least non-storage untested non i386-specific > drivers into amd64 kernel and/or at least in HEAD to give them testing > and a wider exposure. > > This is not just idle interest for me - recently our company has > started shipping amd64 version of our FreeBSD-based product, so that > we are a little bit concerned about hardware support with amd64 7.1 > kernel being a little bit narrower compared to i386 7.1 kernel. > > I apologize if this topic has been discussed somewhere already. I think the answer to your question about default-enabling drivers is very clear: it is the decision of the person maintaining the driver. If you're willing to SUPPORT a driver on a platform then feel free to enable it. Otherwise doing a drive-by to enable a driver that may or may not work may easily result in complaints that are unanswered. These have resulted in people concluding wider breakage that easily becomes de-facto and are hard to kill given that people google for help, find old complaints, and stop searching. Sam