[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080514193822.GA21795@cs181133002.pp.htv.fi>
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