linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-ide@vger.kernel.org, Jeff Garzik <jeff@garzik.org>
Subject: Re: [PATCH] libata-sff: trivial corrections to Kconfig help text
Date: Sun, 30 May 2010 10:46:09 +0200	[thread overview]
Message-ID: <4C0225D1.90205@kernel.org> (raw)
In-Reply-To: <4C0135BF.1010505@s5r6.in-berlin.de>

Hello,

On 05/29/2010 05:41 PM, Stefan Richter wrote:
>> Hmmmm... maybe we can emphasize the 'if unsure, say Y' part?
> 
> I did follow that recommendation but was still left curious. :-)

Maybe it should be changed to "You're supposed to be unsure, say Y,
dammit!" :-)

>>> Or could that option even be hidden and 'select'ed by bus master DMA
>>> capable ATA SFF drivers?
>>
>> I wanted to make the distinction clear so made the option explicit.
>> Opinions on whether that is actually a good idea would differ but at
>> the same time, I don't think this would cause any problem, would it?
> 
> OK, I first came across it by way of make oldconfig.  Then I read the
> changelog and still wondered.  Now I had a look at the menu layout in
> gconfig and it makes sense to me now.
> 
> Just from the looks of the menu, would calling the prompt
> 
> 	bool "SFF controllers with bus master DMA"
> 
> be sensible?  After all, this option does not just control whether a
> certain capability is built into libata, switching it on pulls up the
> Kconfig prompts for a whole range of controller drivers.  (Ok, the help
> text is saying exactly this, but then the prompt could do so already...)

Yes, sure.  Can you please combine this with the original patch?

> The 'hidden variable + select' way would be more friendly to "make
> oldconfig", but I see now that it would take quite a few select
> statements to be added.

Yeah, that and I *really* wanted to make the distinction explicit
because ambiguous dependeny has been a problem for some time.  Now a
driver will end up in a different config section which is always
visible depending on its dependencies, so I like this much better.

Thanks.

-- 
tejun

  reply	other threads:[~2010-05-30  8:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-29 10:47 [PATCH] libata-sff: trivial corrections to Kconfig help text Stefan Richter
2010-05-29 12:38 ` Tejun Heo
2010-05-29 15:41   ` Stefan Richter
2010-05-30  8:46     ` Tejun Heo [this message]
2010-05-30 14:00       ` [PATCH] libata-sff: clarification and trivial correction to Kconfig text Stefan Richter
2010-05-30 15:05         ` Tejun Heo
2010-06-02 17:50 ` [PATCH] libata-sff: trivial corrections to Kconfig help text Jeff Garzik

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=4C0225D1.90205@kernel.org \
    --to=tj@kernel.org \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    /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).