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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 14 Oct 2007 12:40:35 +0200
From:	"Markus Rechberger" <mrechberger@...il.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	mchehab@...radead.org, torvalds@...ux-foundation.org,
	linux-dvb-maintainer@...uxtv.org, video4linux-list@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB changes for 2.6.24

On 10/11/07, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Thu, 11 Oct 2007 01:00:39 +0200
> "Markus Rechberger" <mrechberger@...il.com> wrote:
>
> Please don't send 900 line emails to which you have added only an additional
> paragraph.
>
> > >  drivers/media/video/em28xx/em28xx-core.c           |    1 -
> > >  drivers/media/video/em28xx/em28xx-input.c          |    1 -
> > >  drivers/media/video/em28xx/em28xx-video.c          |    6 +-
> >
> > not accepted
>
> Until your attempt to get the userspace-driver work merged into the kernel
> is successful (and from my reading of last month's discussion it is nowhere
> near that), we should continue to maintain the present driver.
>
> If you choose to not participate in that maintenance then others will need
> to do their best in this regard.
>
> What we should not and will not do is to permit the current driver to be
> held hostage to your attempt to force a controversial and apparently
> unwelcome change into the tree.
>

(please read through it ... )

I didn't comment this one yet, so here a few further details. Note I'm
not looking forward to annoy other developers I want to get that
driver completly done.

some background information on the further userspace idea:
http://lists.freebsd.org/pipermail/freebsd-multimedia/2007-September/007497.html

short overview, this driver has moved a massive amount to userspace:
libtuner/
        (libtuner.so) User-mode drivers for tuners, demodulators, and anything
else that constitutes the "frontend".

So how is this related to my project? This project can reuse all the
userspace demods and tuner code which I have as they are including the
floating point stuff.

I had a discussion with Hans Verkuil (the IVTV maintainer) about my
requirements and his answer was:

2:06 <hverkuil> - However, it is a fact that the relationship between
you and the linux(tv) community are strained to put it mildly. I
remain convinced that none of this has any technical basis but has all
to do with personality conflicts. To be honest, right now I think
there is no solution in sight. This is a valid reason to consider
stopping.

the reason why I take the em28xx as hostage is, well I started with it
and I work with that company and I don't see a way how to implement
the latest devices without terrible hacks (and there are around 60
devices supported only by the current available driver and it will
double that number since customers will change several chips on those
boards)

Due those "personal" conflicts I don't see how I can discuss it with
the linuxtv people who are against me, I even tried to discuss this
with Mauro (who never worked with a company in that area actually so
he doesn't seem to understand what I try to achive, at least I haven't
heard any technical reason why that work should be bad).

Without any help to take aside those personal issues I don't see how
this can be solved.
I pulled all my linux opensource projects offline till this is cleared
up I don't want to do 90% of all work and people taking over my
project doing 10% of hacks for getting some credits. The long time
support is not related to linux only.

As for the BSD project, the developers who work with kaffeine and xine
are fine with another interface which can support those BSD drivers,
as for the linux world it would mean an easy abstraction to use
i2c-dev with the existing userspace drivers without having to change a
single line in those drivers.

sorry for bothering but it seriously cost alot of my private time as well,
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ