From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R8b4r-0004ro-8I for garchives@archives.gentoo.org; Tue, 27 Sep 2011 17:04:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31AF121C117; Tue, 27 Sep 2011 17:04:07 +0000 (UTC) Received: from mail2.viabit.com (mail2.viabit.com [65.246.80.16]) by pigeon.gentoo.org (Postfix) with ESMTP id 79A6921C22D for ; Tue, 27 Sep 2011 17:03:04 +0000 (UTC) Received: from [10.1.1.204] (unknown [65.213.236.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.viabit.com (Postfix) with ESMTPSA id 171BD37B49 for ; Tue, 27 Sep 2011 13:03:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orlitzky.com; s=mail2; t=1317142984; bh=qszorum/+3O8Y+I6WNGe3lhTshqGvF5+LmHCkAPxfNk=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=uJTT73GPMAMSW6CMWFx0ksax4fwHNjdI0hVkqCRXOtqHeHE6fSOQyDc4cHFJcTPAL AlkHPLO4gZ3bD0+BeeOyzzLjaKPUseJNK/0CkA90inhj/+onT/giNRwpdvzCPOzwhd +YaqeHVhElg1h/of45nRX9/FqgL7TkSn0zkHknYU= Message-ID: <4E8201C7.8050400@orlitzky.com> Date: Tue, 27 Sep 2011 13:03:03 -0400 From: Michael Orlitzky User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110924 Lightning/1.0b3pre Thunderbird/3.1.12 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Slightly OT but interesting nonetheless... References: <4E80D466.7010804@coolmail.se> <4E8114F0.8080608@orlitzky.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: X-Archives-Hash: 6e49ff798a5269964d27c9abbfc75c4e On 09/27/11 00:05, Grant Edwards wrote: >> >> Contribute your drivers upstream. When the devs change an API, they'll >> update your code for you. > > That sounds good, but in practice it doesn't work. > > 1) The kernel developers don't support any existing customers. Bugs > are only fixed for customers who are willing to run the next > kernel verison. I've got customers that are still running 2.4 > kernels. 2.6.18 is still widely used. Will the kernel developers > add new features, support for new hardware, or fix bugs for those > customers. Not a chance. If your users don't upgrade their kernel, then the API doesn't change, and there's no problem for these customers, right? > 2) The kernel developers only make sure that drivers compile. They > don't have the hardware or knowlege required to actually test > them. One of our drivers _is_ in the kernel. Sure, it builds, > but AFAIK, it hasn't actually worked for at least 10 years. > > Trying to maintain two drivers (one in-kernel and one out-of-kernel) > just creates twice as much work for no gain. > So (assuming the devs do break your stuff occasionally) you have to test and possibly fix at least one driver whenever the API changes. I see a few options: 1) Test/fix one driver, in-kernel (less work) 2) Test/fix one driver, out-of-kernel (more work) 3) Test/fix two drivers, one in- and one out-of-kernel (most work) In any case, even if I'm wrong about the amount of work involved, it would be nicer for your customers if they didn't have to ask your permission to upgrade the kernel.