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]

Message-ID: <20080514165434.GC22115@cs181133002.pp.htv.fi>
Date:	Wed, 14 May 2008 19:54:34 +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 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.

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

I can make a patch for it after this pull went into Linus' tree if it is 
considered an acceptable option.

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