linux-kernel - Re: [PATCH] configfs: change depends -> select SYSFS

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: <20110117000558.GG22723@ZenIV.linux.org.uk>
Date:	Mon, 17 Jan 2011 00:05:58 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Joel Becker <jlbec@...lplan.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	James Bottomley <James.Bottomley@...e.de>
Subject: Re: [PATCH] configfs: change depends -> select SYSFS

On Sun, Jan 16, 2011 at 03:45:35PM -0800, Linus Torvalds wrote:

> And now ask yourself, do you really expect some random user to say "I
> want to enable SYSFS and CONFIGFS, because I am going to use ocfs2 on
> my system"?
> 
> Really?
> 
> Or do you expect a high-quality implementation of a configuration
> script to allow the user to just say "I want ocfs2", and then figure
> out the dependencies and solve them for you?
> 
> I'd say that the latter case is OBVIOUSLY the quality implementation,
> while the former one is just stupid.

It's a bit more complicated than that...
	* nitpick: config option for a driver foo should be seen only after
foo got enabled, so that's another case where we need depends on
	* nitpick 2: some switchable things really shouldn't be selectable,
or you'll get users wondering which of the drivers they'd enabled had
lead to 32bit kernel on their amd64 boxen ;-)
	* all nitpicks aside, there ought to be a way to say "no, I _REALLY_
don't want that shit doing #define if(x) <horrible pile of crap> and if it
means that I can't have oprofile, so be it".  Without chasing tons of select
chains to see which FPOS do I need to disable to get rid of the damn thing.
Right now the propagation of select chains makes it more and more unpleasant.

IOW, it would be very nice to be able to pin a select target down, turning
selects leading to it into hard dependencies.

Another obviously missing thing is that dependencies should propagate back
through select chains.  I.e. if A selects B, then hard dependencies of B
should append to those of A.

It gets really lousy when you have shitloads of drivers spread over several
Kconfig menus, all selecting an option that has a hard dependency.  As it
is, if you want e.g. allmodconfig to produce something that builds you have
to chase them all down and add dependencies to each of those drivers.  We
have such piles in e.g. drivers/media.
--
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/