From owner-svn-src-all@FreeBSD.ORG Mon Jan 19 09:24:46 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 B08DD1065677; Mon, 19 Jan 2009 09:24:46 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 7850A8FC1C; Mon, 19 Jan 2009 09:24:46 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n0J9Oil7090153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 01:24:45 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <497446D4.5020104@FreeBSD.org> Date: Mon, 19 Jan 2009 01:24:36 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Scott Long References: <200901190710.n0J7ACSg001385@svn.freebsd.org> <497432A1.9060805@samsco.org> In-Reply-To: <497432A1.9060805@samsco.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 09:24:47 -0000 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. -Maxim