linux-kernel - Re: Linux 2.6.26-rc1

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] [day] [month] [year] [list]

Date:	Thu, 08 May 2008 16:11:53 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
CC:	Alistair John Strachan <alistair@...zero.co.uk>,
	Robin Holt <holt@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.26-rc1

Mauro Carvalho Chehab wrote:
> In the case of those tuners, all have the same dependencies:
> DVB or V4L and I2C. That's the reason why I've removed the
> individual dependencies.

Which I just wrote is dangerous.  It is easy to get wrong, and it is not
maintainable.

Here is what I would do:

config TUNER_1
	tristate "Tuner 1"
	depends on ACTUAL_DEP1_OF_T1 && ACTUAL_DEP2_OF_T1

config TUNER_2
	tristate "Tuner 2"
	depends on ACTUAL_DEP1_OF_T2 && ACTUAL_DEP2_OF_T2
	select ACTUAL_DEP3_OF_T2

In this example, ACTUAL_DEP3_OF_T2 does not have further dependencies
itself.

And if you believe that Kconfig should assist with runtime dependencies
too, not just build-time dependencies, and you believe that the "help"
and "comment" directives are insufficient for that, then add
meta-options like this:

config META_TUNER_A
	tristate "Meta-tuner A"
	select TUNER_1
	depends on ACTUAL_DEP1_OF_T1 && ACTUAL_DEP2_OF_T1  # for TUNER_1
	select TUNER_2
	depends on ACTUAL_DEP1_OF_T2 && ACTUAL_DEP2_OF_T2  # for TUNER_2
	select ACTUAL_DEP3_OF_T2                           # for TUNER_2
	help
	  Adds support for cards which contain tuner 1 and/or tuner 2.

So, like I said before, I recommend:

  - If an option has an actual build requirement, state it explicitly
    by "depends on" (or alternatively "select") directly at this option.

    Alternatively, enclose this option or a block of options which
    have identical dependencies in an "if"/ "endif" block, conditional
    on this common dependency.

  - Whenever you use "select", *copy* all dependencies of option A to
    option B if B selects A.

    Alternatively, replace "select" by "select ... if C" and *copy*
    all dependencies of option A to option C.

This is because the Kconfig files (1.) must correctly state all build
dependencies and (2.) must be maintainable.

If you "select" a lot, you will have of course a lot of dependencies to
copy.  That's the nature of "select".  You can't get around that.  Not
as long as there is no "select" which recursively checks and maybe
selects dependencies of dependencies.
-- 
Stefan Richter
-=====-==--- -=-= -=---
http://arcgraph.de/sr/
--
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/