From: Matthew Wilcox <matthew@wil.cx>
To: Adrian Bunk <bunk@stusta.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>,
Andrew Morton <akpm@osdl.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 13/16] GFS2: Makefiles and Kconfig
Date: Fri, 21 Apr 2006 11:07:53 -0600 [thread overview]
Message-ID: <20060421170753.GW24104@parisc-linux.org> (raw)
In-Reply-To: <20060421165351.GG19754@stusta.de>
On Fri, Apr 21, 2006 at 06:53:51PM +0200, Adrian Bunk wrote:
> On Fri, Apr 21, 2006 at 10:49:10AM -0600, Matthew Wilcox wrote:
> > On Fri, Apr 21, 2006 at 06:43:09PM +0200, Adrian Bunk wrote:
> > > - "depends on SYSFS" instead of the select
> >
> > Why? It's more natural to select it rather than depend on it.
>
> The rule of thumb is that an option is either user visible and should be
> depended on or not user visible and should be select'ed.
What rubbish! Who came up with this rule of thumb?
My rule of thumb is that if an option is infrastructure, then it should
be selected. If it's an addition, then it should be depended.
For example, in SCSI, the transport attributes are individually
selectable, but any driver that wants to use a transport selects it.
It would be foolish to have to answer questions from users who want to
know why they can't select SCSI_AHA152X any more and are told they have
to enable the obscure piece of infrastructure.
An exmaple in the other direction is BRIDGE_NETFILTER. It would be
silly to *not* depend on NETFILTER. The user has said they don't want
to do any kind of network filtering, so would only get annoyed at being
asked about different kinds of network filtering.
This case is clearly infrastructure. The user knows whether or not
they want GFS. If they have to enable sysfs to get GFS, this will only
perplex them.
Obviously, it's not always easy to figure out whether the relationship
between two pieces of code is infrastructure or addition. Sometimes
it's a judgement call.
next prev parent reply other threads:[~2006-04-21 17:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-21 16:22 [PATCH 13/16] GFS2: Makefiles and Kconfig Steven Whitehouse
2006-04-21 16:43 ` Adrian Bunk
2006-04-21 16:49 ` Matthew Wilcox
2006-04-21 16:53 ` Adrian Bunk
2006-04-21 17:07 ` Matthew Wilcox [this message]
2006-04-21 20:56 ` Sam Ravnborg
2006-04-21 23:00 ` Greg KH
2006-04-24 13:24 ` Steven Whitehouse
2006-04-24 13:32 ` Steven Whitehouse
2006-04-21 21:01 ` Sam Ravnborg
2006-04-24 13:27 ` Steven Whitehouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060421170753.GW24104@parisc-linux.org \
--to=matthew@wil.cx \
--cc=akpm@osdl.org \
--cc=bunk@stusta.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swhiteho@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).