linux-kernel - Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

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: <46360B9A.2040605@linuxtv.org>
Date:	Mon, 30 Apr 2007 11:30:34 -0400
From:	Michael Krufky <mkrufky@...uxtv.org>
To:	Uwe Bugla <uwe.bugla@....de>
CC:	Markus Rechberger <mrechberger@...il.com>, hermann-pitton@...or.de,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	linux-dvb@...uxtv.org, linux-kernel@...r.kernel.org,
	Trent Piepho <xyzzy@...akeasy.org>
Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

Uwe Bugla wrote:
> And I swear that this dvb-pll.c is completely obsolete for this scenario!
> For that reason (old variant):
> # CONFIG_DVB_TUNER_LGH06XF is not set
>
> And this old variant was NOT done by Trent Piepho, it was NOT done by Andrew Quincey,
> but it was produced by Michael Krufky himself, and I was very thankful for that and still am!
>
> [...]
>
> And why the hell is that dvb-pll.c rollback part of git2 now?
> Additionally - with the acknowlegdement of Michael Krufky - incredible!
The LG-H06xF NIM is slightly different from the other tuners supported
by the dvb-pll library, in that it requires a 5th auxiliary byte, as
opposed to only four bytes that are sent for all of the other devices
supported by dvb-pll.  In order to handle this, I had created a separate
module, called lgh06xf.  This module was able to re-use some code inside
the dvb-pll module, while adding the additional required code to handle
that 5th byte.

As a side effect, caused by the creation of the lgh06xf module, the
static dependency of dvb-bt8xx on dvb-pll was removed.  Instead of
dvb-bt8xx having to call dvb_pll_configure, causing the static
dependency, it would now call lgh06xf_attach.  lgh06xf_attach would fill
the dvb_tuner_ops, and the call to dvb_pll_configure was moved into the
lgh06xf module.  This change was done in an effort to improve support
for the LG-TDVS-H06xF NIM family...  The removal of the static
dependency of dvb-bt8xx on dvb-pll was merely a side effect.  I DID NOT
DO THIS FOR YOUR BENEFIT, UWE.  There is always a chance that a new
bt8xx-based card may come around with a new tuner, and need the dvb-pll
module in order to work properly.

Then, Trent suggested that we add this 5th byte functionality to
dvb-pll.  Trent has shown us how this 5th byte is helpful for other
devices, including the Thomson DTT 761X, and the Philips FMD1216ME,
among others.  Trent made the appropriate changes to the dvb-pll module,
allowing it to absorb the functionality of the lgh06xf module into a
centralized location, so that any other tuners can benefit from this
shared code.  Trent did a great thing here, by making the dvb-pll module
a much more robust library, not to mention that his changes have in fact
REDUCED the size of the kernel.  (see Trent's earlier post in this thread)

Uwe, this is quite a silly argument.  You've been singing the same song
ever since before I got involved with linuxtv.org, and quite frankly, I
am sick of it.

Let it be known to the world, that Uwe has praised me in his previous
emails, as I have kept quiet and ignored his rants.  Now that I am
finally opening up my mouth, I am quite sure that I will be his next
flame target.  Nobody can take this kind of behavior seriously -- the
only thing we can do is ignore you, and maybe you'll go away.

My suggestion to you, Uwe, is to stop flaming the lists, and stop
bothering us developers.  Your devices work.  You are complaining about
wasted memory -- get over it.  It is a small price to pay for globally
supported devices and autodetection.  You should be happy that people
are still here working on this code.  It seems that your emails are
focused at driving away developers -- nothing more could be gained by
this, then everybody is screwed.

If your patches were correct, then, by all means, we would apply them. 
However, developers have pointed out problems in your patches, and you
have done nothing but flame them.  Who wants to continue a discussion
with you, after only being flamed?  I sure don't.

Just know that if you respond to this email with yet another flame, I
will simply ignore it.

-Mike

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