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: <20070913131353.GB26972@linuxtv.org>
Date:	Thu, 13 Sep 2007 15:13:53 +0200
From:	Johannes Stezenbach <js@...uxtv.org>
To:	Markus Rechberger <mrechberger@...il.com>
Cc:	Mauro Carvalho Chehab <mchehab@...radead.org>,
	"linux-dvb@...uxtv.org" <linux-dvb@...uxtv.org>,
	video4linux-list@...hat.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-dvb] [PATCH] Userspace tuner

On Thu, Sep 13, 2007, Markus Rechberger wrote:
> Let's add the LKML to this.
> 
> On 9/13/07, Markus Rechberger <mrechberger@...il.com> wrote:
> > On 9/12/07, Mauro Carvalho Chehab <mchehab@...radead.org> wrote:
> > > I don't see any technical reason why tuner drivers should be moved to
> > > userspace. Looking at xc3028 device, the driver is very simple and
> > > doesn't require any special treatment that it isn't possible to be done
> > > at kernel. There are already some implementations on kernelspace that
> > > works fine.
> >
> > As from my side to support the xceive driver properly it needs a
> > rewrite and a proper API description. Since it's not possible to
> > discuss any API changes

Not possible? We're doing it all the time...

However, your ideas were rejected in this discussion,
and you can't seem to get over it.

> > don't get me wrong but the existing community is rather small and
> > kicking off people who are interested in changing things.

IMHO there is a lack of openness caused by people being burned
in past flamewars. This makes it a bit difficult to see through
what happens and why, and to participate.  However, I think it
is completely wrong to say that the community is "kicking off people".

> > I'm against how the project works out at the moment and how it worked
> > out in history. Exactly this way will kick off companies to be
> > interested in future like Avermedia. A driver can easily be written
> > within a few weeks and I've been struggling with it for 2 years(!!!)
> > now just for nothing finally telling me that some guys want to steal
> > my code and move it to kernelspace although it would raise more
> > complications with upcoming and current devices which have even more
> > requirements.

Oh dear, there we go again... more flame bait...

I reality, 95% of your driver code could have been merged
without problems, but you refused to take the small, objectionable
part out of the picture.

(For those interested:
http://mcentral.de/~mrec/patches/v4l-dvb/hg_v4l-dvb-experimental_01.patch
The patch changed the internal tuner API and required changes
to all tuner drivers.)

Your all-or-nothing approach didn't work out.

Out of curiosity: How does your userspace approach solve
the hybrid (analog/digital TV) tuner problem which was the
only objectionable part of your work? And why are the kernel
parts of your new interface now less objectionable? What changed?


Johannes
-
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/