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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d9def9db0709130908r6e383c51wd115dd56cfe2beef@mail.gmail.com>
Date:	Thu, 13 Sep 2007 18:08:54 +0200
From:	"Markus Rechberger" <mrechberger@...il.com>
To:	"Manu Abraham" <abraham.manu@...il.com>
Cc:	"Johannes Stezenbach" <js@...uxtv.org>,
	linux-kernel@...r.kernel.org, video4linux-list@...hat.com,
	"linux-dvb@...uxtv.org" <linux-dvb@...uxtv.org>,
	akpm@...ux-foundation.org
Subject: Re: [linux-dvb] [PATCH] Userspace tuner

On 9/13/07, Manu Abraham <abraham.manu@...il.com> wrote:
>
> > It's only a step in development, I do not intend to keep the kernel
> > stub in the end, but I do intend to keep and use the userspace drivers
> > with i2c-dev in the long run, this requires a v4l/dvb library at the front
> > of everything.
>
> Well, this was what adq and myself did with libdvbapi and mti, (much
> before UIO was announced at LK.) It is not tied to I2C either.
>

I2C is the main communication path for it, although there are callback
mechanisms available which add the possibility for different configuration
paths.

> But, according to your statements (with regards to i2c-dev) you can
> handle only some I2C based devices, which is in fact a subset of a
> subset. Also not to forget that hardly a few I2C devices are in fact
> "truly" I2C compatible. In fact many variables to be considered.
>

The analogue tuner core is also only for i2c only devices which most
devices rely on.

> 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.

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