From owner-svn-src-all@FreeBSD.ORG Mon Jan 19 17:12:48 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 B8305106566B; Mon, 19 Jan 2009 17:12:48 +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 63E738FC1C; Mon, 19 Jan 2009 17:12:48 +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 n0JHCkWM014595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 09:12:47 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <4974B484.7030608@FreeBSD.org> Date: Mon, 19 Jan 2009 09:12:36 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Sam Leffler References: <200901190710.n0J7ACSg001385@svn.freebsd.org> <497432A1.9060805@samsco.org> <497446D4.5020104@FreeBSD.org> <4974ABCC.7000107@freebsd.org> In-Reply-To: <4974ABCC.7000107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; 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 17:12:49 -0000 Sam Leffler wrote: > 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. OK, makes sense. By the way, there is a question on this topic to you. The wi(4) has been removed from i386 GENERIC, but it is still present in amd64 GENERIC. Is it intentional or just a mistake? -Maxim