M. Warner Losh wrote:
In message: <4974b484.7030...@freebsd.org>
Maxim Sobolev <sobo...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
