Date: Mon, 19 Jan 2009 17:33:15 -0800 From: Sam Leffler <sam@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r187426 - head/sys/amd64/conf Message-ID: <497529DB.5050903@freebsd.org> In-Reply-To: <20090119.181606.1887043661.imp@bsdimp.com> References: <497446D4.5020104@FreeBSD.org> <4974ABCC.7000107@freebsd.org> <4974B484.7030608@FreeBSD.org> <20090119.181606.1887043661.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote:
> In message: <4974B484.7030608@FreeBSD.org>
> Maxim Sobolev <sobomax@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497529DB.5050903>