linux-kernel - Re: [GIT PATCHES] V4L/DVB fixes for 2.6.26

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:	Wed, 14 May 2008 14:55:54 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Adrian Bunk <bunk@...nel.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, 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 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
--
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/