From owner-svn-src-all@FreeBSD.ORG Tue Jan 20 01:33:19 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 2A84B1065675; Tue, 20 Jan 2009 01:33:19 +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 D62BF8FC1F; Tue, 20 Jan 2009 01:33:18 +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 n0K1XFqB062616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 17:33:16 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <497529DB.5050903@freebsd.org> Date: Mon, 19 Jan 2009 17:33:15 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: "M. Warner Losh" References: <497446D4.5020104@FreeBSD.org> <4974ABCC.7000107@freebsd.org> <4974B484.7030608@FreeBSD.org> <20090119.181606.1887043661.imp@bsdimp.com> In-Reply-To: <20090119.181606.1887043661.imp@bsdimp.com> 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: Tue, 20 Jan 2009 01:33:19 -0000 M. Warner Losh wrote: > In message: <4974B484.7030608@FreeBSD.org> > Maxim Sobolev writes: > : 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? > > I'd remove it from amd64 too. It isn't terribly useful these days > outside of open access points. > > Er that's not true; wi supports WPA w/ the cards it works with. And it does WPA w/ hostap too. If someone wanted to make an effort the set of cards it supports could also be brought back to where it was before I took an axe to the code (though older cards wouldn't support WPA). Sam