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: <d9def9db0709170146u7827d43axf4f2dcf8bb80b352@mail.gmail.com>
Date:	Mon, 17 Sep 2007 10:46:25 +0200
From:	"Markus Rechberger" <mrechberger@...il.com>
To:	"Bernard Jungen" <bern8817@...honynet.be>
Cc:	"Mauro Carvalho Chehab" <mchehab@...radead.org>,
	"video4linux-list@...hat.com" <video4linux-list@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-dvb@...uxtv.org" <linux-dvb@...uxtv.org>
Subject: Re: [linux-dvb] [PATCH] Userspace tuner

On 9/15/07, Bernard Jungen <bern8817@...honynet.be> wrote:
> On Sat, Sep 15, 2007 at 11:04:42AM -0300, Mauro Carvalho Chehab wrote:
> > With respect to your kernel-userspace API for xc3028, you made something
> > that seemed to be a dream: there's a consensus: not a single developer
> > believed that this is the better way; nobody seems that this is the
> > better approach.
> >
> > So, or you are the only media developer with good sense in the face of
> > the Earth, or you're incapable of understand the obvious: you're wrong
> > with this approach. IMO, the answer is quite obvious.
>
> Yes, as a newbie observer on the v4l list, the answer is obvious to me,
> at last, and the reason is not entirely technical. I can't read so many
> bogus arguments on so few lines without reacting.
>
> Rephrasing Mauro:
>
> "Not a single developer out of a few SEEMS to believe that it is the BETTER
> approach, so since the FEW represent ALL media developers in the world, and
> since there is only ONE RIGHT way to do things, and since the GROUP is
> always RIGHT and always knows better than the individual, then YOU're WRONG
> and I'm right. Conform to the group and do as the group says, whatever the
> consequences!"
>
> Geeks are decidedly as prone as others to blindly accept travelling on the
> slippery road of herd mentality and "obvious" conclusions based on
> appearances. Is this OPEN source development or a dictatorship or what?
>
> So in the end Mauro will be right. And Markus will continue to develop and
> defend his stuff as HE sees fit. He knows his own work better than anyone
> else. It will be HIS way or nothing with his own stuff, it's his inalienable
> right.
>
> And don't be naive, if there's no solution more viable than Markus' one,
> then the latter will eventually be widely adopted somehow, sometime,
> whatever the amount of grumbling from the establishment. No
> dictatorship/forced consensus can decide future's direction, nor improve
> its already low own viability.
>

I see it exactly the same way.

Well I will continue to provide an alternative stack with alternative drivers.
The peer review shows that it doesn't work too well without people participating
fixing problems, the initial drivers were inkernel based and due some updates in
modules which are used by the em28xx some devices which previously worked
don't work anymore in the kernel.

As for the em28xx the driver will use userspace i2c based tuners, decoders and
demodulators.
The userspace modules will use unaltered sample drivers which are provided by
several companies, which also saves alot time in future for that project.
Those drivers will also officially be provided and recommended by the
manufacturing company of those devices, including the proper firmware.
Personally I won't spend any time on reinventing the wheel and fixing drivers
which get broken by not taking care of it.

Beside that people are welcome to contribute without having to fear a political
overhead of discussing requirements and other issues when changing the
corresponding alternative core code. The project and how it will/should go on
is documented at mcentral.de.

I also see that as a good way for the community, that way the linuxtv guys
have to prove that they can be open to other people without adding too
much noise and overhead otherwise people will contribute to the alternative
project as some already do.

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/