Re: [linux-dvb] [PATCH] Userspace tuner

From: Steven Toth
Date: Thu Sep 13 2007 - 21:29:14 EST

Markus Rechberger wrote:
On 9/13/07, Steven Toth <stoth@xxxxxxxxxxxxx> wrote:
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.

Steven,

what stops vendors of using the current existing code to achieve that
goal. They could provide binary drivers with the existing API.


Because the good people in this mailing list are keeping them honest. Give any board or silicon company the ability to protect their IP, even in the smallest way and they'll do it, and for no good technical reason. It's a cut throat market and it's not clear that everyone understands just how thin sales margins really are.

That means Hauppauge potentially releasing a binary driver, because it's much easier than seeking silicon vendor permission for a public diver. The net result of that would mean I'd have to leave the company and find another company that practices the one thing I truly care about .... open source and open development groups.

I'm keeping Hauppauge honest with their Linux involvement and I'm not alone. Other devs in other linux subsystems in other companies are doing the same thing.

Binary drivers (or binary components) leads Linux back in time.

I can't believe your so passionate about protecting secrets.

What stops companies to intercept the ioctl calls and overriding some
I2C commands?


Why would a company want to do that? Companies don't do that, hackers do that.

Since you know about windows drivers (at least I think that you know
about it) you might know about the limitations of the v4l/dvb API
in general the reason just put as much code as possible into the
kernel just for forcing companies to release code under GPL doesn't
seem to be valid.

It seems perfectly valid to me.

How about proprietary video formats, would you also place the decoding
algorithms in kernel just to force companies to release their code
for it?

The kernel has no good API for those, each new type of video device and suggested API is judged on it's own merits and discussed on the mailing lists.

What do you think about the existing usbfs implementation, which
allows to implement usb drivers completly in userspace?

Those are not my problem and I don't use them, you should raise that with the relevant usb-dev mailing lists. I'm here because I care about linuxtv. Please stay on topic.

What do you think about IOMMU?

Just because AMD or INTEL want to invent some whizzy new technology it doesn't say anything about the TV card development and retail business. Intel and AMD have teams of Linux engineers helping operating system developers bring their ideas and technologies to new platforms. That's a million miles away from any of the TV board vendors I know of, who have little or NO fulltime linux developers and consider the < 5% market fringe at best.

Markus, senior devs in the LinuxTV group are telling you, based on their commercial experience, that userspace access is technically great, but long term it will be used against the community and will ultimately hurt linuxtv development.

If you want to reply and have the last word, go ahead, but repeating what I've said on this list in the past - I'll never support the userland tuning/demod idea.

I wanted to work directly with you on the em28xx tree, helping you remove the 5% of code that Johannes referred to, but you said no. I wanted to help you make the tree conform to the linuxtv standards for frameworks, you said no.

If you care about LinuxTV you'll work with the core subsystem developers to bring your em28xx tree inline. If you don't care then why are you here?

- Steve







-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/