linux-kernel - Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24

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: <c8b4dbe10710110250w10ddfc0du6ae4b6bb95cb2d2f@mail.gmail.com>
Date:	Thu, 11 Oct 2007 10:50:28 +0100
From:	"Aidan Thornton" <makosoft@...glemail.com>
To:	"Markus Rechberger" <mrechberger@...il.com>
Cc:	"Chuck Ebbert" <cebbert@...hat.com>, video4linux-list@...hat.com,
	linux-kernel@...r.kernel.org,
	"Mauro Carvalho Chehab" <mchehab@...radead.org>,
	linux-dvb-maintainer@...uxtv.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24

On 10/11/07, Markus Rechberger <mrechberger@...il.com> wrote:
> On 10/11/07, Chuck Ebbert <cebbert@...hat.com> wrote:
> > On 10/10/2007 07:24 PM, Markus Rechberger wrote:
> > >
> > > To point to more changes within the available driver which hasn't been
> > merged
> > > within the last 1 1/2 years:
> > > * it supports non usbaudio based video devices.
> > > * has support for dvb-t/atsc
> > > * allows multiple device node access in case of analogue TV
> > > * has teletext/VBI support for PAL.
> > > * it supports modules which are now in userspace instead of
> > > kernelspace due disagreements with some developers for 1 1/2 years.
> > > * I do not agree with certain developers who do not have any experience
> > > with certain parts of the code for redoing it a 4th time now. My patience
> > > is over, which includes the company support in my back to get those
> > > devices supported.
> > >
> >
> > Do you plan on maintaining your own private driver tree for all of eternity?
> >
>
> I plan to tidy it up for inclusion and put everything together to get
> it work properly.
> The code which is in the kernel is around 5 % done, the code which is
> available on mcentral.de is around 50% done. It still requires some
> work to get _all_ devices supported, and keeping the development
> process in an endless loop and depending on people who have no idea
> and don't care about certain requirements is no option.
> The upcoming devices which use other chips and which have more
> features will at least also use those drivers. I expect that it will
> pump up the driver to support more than 100 devices within the next
> year.

I looked at this recently, and I'm not sure the core em28xx code was
really that different (at least, pre-userspace). Most of the core
changes seemed to be related to Markus' driver having (semi-working)
VBI support. I haven't tried this recently; I disabled it a while back
because it had a bug that caused a kernel panic half the time when
attempting to record something with MythTV.

The in-kernel driver looks mostly sound, though I can't test it
myself. (One other interesting thing that was added in Markus' driver
is various v4l1 ioctls, which may be useful to some people.)

Incidentally, I notice you appear to be developing userspace drivers
for the tvp5150 and zl10353. Is that really necessary?

> * I do not agree with certain developers who do not have any experience
> with certain parts of the code for redoing it a 4th time now. My patience
> is over, which includes the company support in my back to get those
> devices supported.

Are you threatening to deliberately sabotage company support for these
devices by v4l/linuxtv in favour of your userspace drivers?

Also, I'm not sure reworking the non-userspace version of the code to
a mergable state is actually that hard. (I'm cleaning up bits of it in
my spare time, because I may have to port it to newer kernels myself
in the future and it's annoying to work with as-is.) Eliminating the
need for changes to the core v4l/dvb code appears to be the easy bit;
the main difficulty is finding and fixing the unexpected breakages due
to the interesting coupling between bits of the code. (The other
difficulty is keeping track of whether analog or digital firmware is
currently loaded in the xc3028 in hybrid devices; I'm using an iffy
solution, but I think better ones exist.) As I recall, the changes to
core code were the major roadblock in the way of merging.

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