Date: Mon, 19 Jan 2009 19:14:32 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: sam@FreeBSD.org 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: <20090119.191432.-2040405057.imp@bsdimp.com> In-Reply-To: <497529DB.5050903@freebsd.org> References: <4974B484.7030608@FreeBSD.org> <20090119.181606.1887043661.imp@bsdimp.com> <497529DB.5050903@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <497529DB.5050903@freebsd.org>
Sam Leffler <sam@freebsd.org> writes:
: 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).
You are correct. My cards have old crummy firmware on them, and what
I said is true about them. Most of the wi cards can support it, but
most (many?) of them have firmware that lacks this.
The firmware is available, and loading it into RAM isn't a huge deal.
Just a tedious one to get right...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090119.191432.-2040405057.imp>