linux-kernel - Re: [PATCH 13/13] fix ps3fb glue allowing a modular build

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: <Pine.LNX.4.64.0703141016060.9690@woody.linux-foundation.org>
Date:	Wed, 14 Mar 2007 10:30:31 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@....linux.org.uk>
cc:	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>,
	linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 13/13] fix ps3fb glue allowing a modular build

On Wed, 14 Mar 2007, Al Viro wrote:
> 
> Nope.  How can kconfig distinguish that from a boolean option in modular
> driver?  bool *can* depend on tristate and be selected when tristate is
> set to m.

Btw, this is one of those things that easily causes problems.

In many ways it would be nice if we had two different kinds of "bool": one 
where "m" in the dependency chain means "y" is ok, and one where "m" means 
"n".

We used to have "dep_bool" and "dep_mbool" for this, a long time ago. It 
got dropped in the Kconfig language rewrite, and I think it was a mistake.

So I think it would be nice to re-introduce it. As it is, we have a number 
of Kconfig language constructs that are just unnecessarily hard to 
understand, because we end up having to add a "= y" or similar.

The rule *used* to be: "dep_mbool" was a boolean that was valid even for 
modules, while "dep_bool" was a boolean that was valid only for straigth 
"y", and a module would turn it off.

Maybe not "bool" vs "mbool", but it might be nice to have

	bool FB_PS3
		depends strictly on FB

ie a "depends strictly" refuses to upgrade a bool dependency from "m" to 
"y", while a regular depends allows it.

Or something.. The "depends strictly on X" thing would really be just a 
mental shorthand for "depends on (X)=y" (it's actually longer to type, but 
I think it's a bit more intuitive, thus "mental shortcut").

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