linux-kernel - 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]

Date:	Sun, 29 Apr 2007 18:37:00 -0700 (PDT)
From:	Trent Piepho <xyzzy@...akeasy.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Uwe Bugla <uwe.bugla@....de>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, mchehab@...radead.org,
	mkruky@...uxtv.org, linux-dvb@...uxtv.org
Subject: Re: Critical points about kernel 2.6.21 and pseudo-authorities

On Sun, 29 Apr 2007, Linus Torvalds wrote:
> On Sun, 29 Apr 2007, Uwe Bugla wrote:
>
> > BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code
> > in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and signed-off-by Mauro Carvalho Chehab:
>
> You never explained what the problem even was, apart from compiling in
> some code that you didn't need to before. Didn't it work in the end?
>
> If it worked, I don't see what the big issue was. You are getting a _lot_
> of other code in the kernel that you probably never use, you may not even
> have realized.

I'd like to explain this a bit, for people seeing these messages who haven't
been following this part of dvb development.

dvb-pll is a simple driver for a number of I2C tuners, which are used in
many many TV cards.

These are simple devices, and drivers for host controllers (which usually
support quite a few different models of tv card based on the same core chip)
often didn't use dvb-pll.  They would just re-implement an I2C tuner driver,
sometimes more than once in the same file!

The dvb tree ended up with over a dozen different re-implementations of the
same basic tuner driver.  Of course each implementation would have different
bugs, quirks, and missing features.

So we've been removing this code and using dvb-pll.  If you look at some of
my patches to do this:

 14 files changed, 14 insertions(+), 199 deletions(-)
 1 files changed, 4 insertions(+), 34 deletions(-)
 4 files changed, 17 insertions(+), 204 deletions(-)

These patches fixed bugs and added features, yet are very much net negative
when if comes to lines of code in the kernel.

> any chance to deselect the compilation of the dvb-pll.c-module, as its
> deselection only works for VIDEO_V4L1_COMPAT, NOT for VIDEO_V4L1.

dvb-pll has nothing to do with VIDEO_V4L1_COMPAT or VIDEO_V4L1.  Uwe is just
confused about what is causing what.

> All the almost excellent work that Michael Krufky has offered for that
> issue at the transition from 2.6.18 to 2.6.19 or 2.6.20 (do not remeber
> exactly) is being wiped out and rolled back with his acknowledgement!

Uwe is probably talking about the dvb_attach() system, written mainly by
Andrew de Quincey and myself, which went into 2.6.18.  The basic concept is
that a core driver uses symbol_request() to avoid any strong references to
its helper drivers.  This way only the helper drivers that are actually
needed must be loaded.  We want to make dvb-pll use this system too, but it
doesn't fully work yet.  I have several ideas about how to solve the
problem, but it's not a high priority.
-
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/