Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Jan 2009 08:35:24 -0800
From:      Sam Leffler <sam@freebsd.org>
To:        Maxim Sobolev <sobomax@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:  <4974ABCC.7000107@freebsd.org>
In-Reply-To: <497446D4.5020104@FreeBSD.org>
References:  <200901190710.n0J7ACSg001385@svn.freebsd.org> <497432A1.9060805@samsco.org> <497446D4.5020104@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

    Sam




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4974ABCC.7000107>