Re: Critical points about kernel 2.6.21 and pseudo-authorities

[Trent Piepho <xyzzy@speakeasy.org>]

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.