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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ