svn commit: r187426 - head/sys/amd64/conf
Maxim Sobolev
sobomax at FreeBSD.org
Mon Jan 19 09:12:49 PST 2009
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
More information about the svn-src-all
mailing list