Date:	Wed, 14 May 2008 22:38:22 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-dvb-maintainer@...uxtv.org, video4linux-list@...hat.com,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [GIT PATCHES] V4L/DVB fixes for 2.6.26

On Wed, May 14, 2008 at 02:55:54PM -0300, Mauro Carvalho Chehab wrote:
> On Wed, 14 May 2008 19:54:34 +0300
> Adrian Bunk <bunk@...nel.org> wrote:
> 
> > On Wed, May 14, 2008 at 11:49:10AM -0300, Mauro Carvalho Chehab wrote:
> > >...
> > > PS.: There are yet a number of other Kconfig potential breakages at V4L/DVB. I'm 
> > > currently working on fixing those issues. Basically, what users do is to select 
> > > I2C, DVB and V4L as module. This works fine, but more complex scenarios where
> > > you mix 'M' and 'Y' inside the subsystem generally cause compilation breakage.
> > > Those scenarios are more theorical, since there's not much practical sense on
> > > having a DVB driver foo as module, and V4L driver bar as in-kernel. However,
> > > the better is to not allow compilation of the scenarios that don't work.
> > > 
> > > The main trouble at drivers/media Kbuild is that several rules there assumed that
> > > "select" would check the "depends on" dependencies of the selected drivers.
> > > However, this feature doesn't exist at the current Kbuild implementation. Even
> > > if implemented, I suspect that this will generate circular dependency errors on
> > > some cases.
> > >...
> > 
> > The basic problem is that drivers/media/ does the most fancy kconfig 
> > stuff in the kernel since it tries to both have very fine grained 
> > dependencies and offer a usable kconfig UI to the user, which results
> > in very complicated dependencies.
> 
> True.
> 
> > We are not getting this solved by any changes in the kconfig 
> > implementation.
> > 
> > Thinking about reasonable ways to reduce the problem space:
> > 
> > Where could we reduce the complexity without big disadvantages?
> > 
> > Could we e.g. let VIDEO_DEV select I2C which would remove all the 
> > fiddling with I2C dependencies (which is a bigger part of recent
> > problems)?
> 
> This seems to be reasonable. However, there are quite a few devices that don't
> need I2C (for example, some legacy ISA radio modules - also, some webcam
> drivers don't use i2c layer to communicate with their i2c sensor - so - they
> don't need I2C. The same also applies to some DVB drivers).
> 
> So, I'm not sure if this would be a good idea, since it will force I2C even for
> devices that don't need. This is bad, for example, on embedded devices like
> set-top-boxes and maybe on cellular phones with non-i2c webcams.

I'm not completely agreeing the space savings you are doing are worth 
the complicated stuff, but OK.

> > I can make a patch for it after this pull went into Linus' tree if it is 
> > considered an acceptable option.
> 
> It would be nice if you could help on fixing those issues.
> 
> One dependency that will probably solve is to add "depends on VIDEO_MEDIA &&
> I2C" to all devices that are hybrid (bttv, saa7134, cx88, pvrusb, em28xx).

What about converting all dependencies on I2C to select's?

VIDEO_V4L2_COMMON might perhaps need a small trick, but otherwise that 
would be a straightforward solution to solve these problems.

Any problem I miss or should I bake a patch?

> Cheers,
> Mauro

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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