From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Adrian Bunk <bunk@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-dvb-maintainer@linuxtv.org, video4linux-list@redhat.com,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [GIT PATCHES] V4L/DVB fixes for 2.6.26
Date: Wed, 14 May 2008 14:55:54 -0300 [thread overview]
Message-ID: <20080514145554.10e3385c@gaivota> (raw)
In-Reply-To: <20080514165434.GC22115@cs181133002.pp.htv.fi>
On Wed, 14 May 2008 19:54:34 +0300
Adrian Bunk <bunk@kernel.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 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).
Cheers,
Mauro
next prev parent reply other threads:[~2008-05-14 17:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-14 14:49 Mauro Carvalho Chehab
2008-05-14 16:54 ` Adrian Bunk
2008-05-14 17:55 ` Mauro Carvalho Chehab [this message]
2008-05-14 19:38 ` Adrian Bunk
2008-05-14 20:04 ` Mauro Carvalho Chehab
2008-05-15 16:02 ` Adrian Bunk
2008-05-16 1:50 ` Mauro Carvalho Chehab
2008-05-16 11:25 ` Adrian Bunk
2008-05-17 10:58 ` Mauro Carvalho Chehab
2008-05-15 0:51 ` [v4l-dvb-maintainer] " Trent Piepho
2008-05-15 2:10 ` Mauro Carvalho Chehab
-- strict thread matches above, loose matches on Subject: below --
2008-04-30 21:10 Mauro Carvalho Chehab
2008-04-30 3:27 Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080514145554.10e3385c@gaivota \
--to=mchehab@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=bunk@kernel.org \
--cc=linux-dvb-maintainer@linuxtv.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®