Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933212AbXIMUqy (ORCPT ); Thu, 13 Sep 2007 16:46:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763195AbXIMUqq (ORCPT ); Thu, 13 Sep 2007 16:46:46 -0400 Received: from mail.hauppauge.com ([167.206.143.4]:3982 "EHLO mail.hauppauge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756890AbXIMUqp (ORCPT ); Thu, 13 Sep 2007 16:46:45 -0400 X-Greylist: delayed 930 seconds by postgrey-1.27 at vger.kernel.org; Thu, 13 Sep 2007 16:46:45 EDT Message-ID: <46E99F36.8090809@hauppauge.com> Date: Thu, 13 Sep 2007 16:36:06 -0400 From: Steven Toth User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Markus Rechberger CC: Manu Abraham , "video4linux-list@redhat.com" , "linux-dvb@linuxtv.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" Subject: Re: [linux-dvb] [PATCH] Userspace tuner References: <46C1BCC5.9090709@amd.com> <1189626560.5160.57.camel@gaivota> <20070913131353.GB26972@linuxtv.org> <46E95C54.4060502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2519 Lines: 68 > >> Also there is to consider a non technical aspect, whether vendors will >> misuse this interface for binary only, undermining the efforts put in >> for OSS drivers. >> >> > > What holds companies for using the current available code putting it > into an rpm or deb package and releasing such code now? > > The Avermedia example I pointed out to is a good example already. > As from my side I won't release binary drivers. > Although on the other side: > * are drivers from vendors which work through several kernel versions > that bad? > * Why did someone duallicense videodev2 with BSD/GPL? > > I would appreciate if someone else on the list could also comment > the reason that drivers should all be included in the linuxkernel just > because forcing the companies to release binary drivers because > of that. My opinion about that is if a company wants to go opensource > they will do so, if not they will either not release a driver or release > nothing. > > I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Read my lips: For commercial reasons, this enables driver components that only work if specific boards are present. - Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/