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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikWHkfb1-Yh_O=rYEqzgz48rwRggCp6uhr+E86J@mail.gmail.com>
Date:	Sun, 16 Jan 2011 15:45:35 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
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 3:19 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> How do you eliminate things like "it really depends on having DMA"?
> When we configure e.g. s390 or uml kernel, it's not like we could
> enable a PCI driver and have architecture magically switch to a
> PCI-supporting one, after all...

If it's something that cannot be changed, then it should be "depends on".

Think about it - writing a "hard requirement" as "depends on" is
perfectly sane. It makes semantic sense, and it is useful to filter
out things that you simply CANNOT have, because you've selected a
configuration or an architecture that simply do not _support_ those
features.

But if it's something where it's not about a feature that is needed,
but about a configuration dependency, it's IMNSHO almost always the
wrong thing to have "depends on".

Another way of thinking about this is to think about what features are
the one that a user *cares* about, and wants to enable or disable by
hand.

Just think about that for a moment - isn't _that_ what a kernel config
should be asking about?

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.

                   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/