public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Bolle <pebolle@tiscali.nl>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Michal Marek <mmarek@suse.cz>, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] [RFC] kconfig: menuconfig make "Selected by:" readable
Date: Thu, 22 Jan 2015 09:50:15 +0100	[thread overview]
Message-ID: <1421916615.13638.35.camel@x220> (raw)
In-Reply-To: <1421915745.13638.27.camel@x220>

On Thu, 2015-01-22 at 09:35 +0100, Paul Bolle wrote:
> On Wed, 2015-01-21 at 18:23 -0800, Randy Dunlap wrote:
> > On 01/21/15 15:00, Paul Bolle wrote:
> > > rev_dep expressions can get rather unwieldy, especially if a symbol is
> > > selected by more than a handful of other symbols. Ie, it's possible to
> > > have near endless expressions like:
> > >    A && B && !C || D || F && (G || H) || [...]
> > > 
> > > Chop these expressions into actually readable chunks:
> > >    - A && B && !C
> > >    - D
> > >    - F && (G || H)
> > >    - [...]
> > > 
> > > Ie, transform the top level "||" tokens into newlines and prepend each
> > > line with a minus. This makes the "Selected by:" blurb much easier to
> > > read.
> > 
> > I agree that something like this needs to be done.
> > 
> > After reading these expressions for a few years, I can handle them OK, but
> > I expect that I look at them more than most people do (with the exception of Paul).
> 
> That's a problem with a broader scope. The specific problem this RFC
> targets is neatly demonstrated by this screenshot: 
>     Symbol: SERIAL_CORE_CONSOLE [=n]
>     Type  : boolean
>      Defined at drivers/tty/serial/Kconfig:805
>   Depends on: TTY [=n] && HAS_IOMEM [=y]
>   Selected by: SERIAL_8250_CONSOLE [=n] && TTY [=n] && HAS_IOMEM [=y] && SERIAL_8250 [=n]=y || SERIAL_AMBA_PL010_CONSOLE [=n] && [...]
> 
> That line ends about two meters to the right of your screen. Really.
> 
> > Here is another confusing one, at least to me:
> > [This is for LBDAF on a 64-biy x86 kernel config.]
> > 
> > Depends on: BLOCK [=y] && !64BIT [=y]
> > 
> > I guess that the value [y,m,n] inside the square brackets is always(?) the
> > symbol value (64BIT) and not the expression value (!64BIT), but that isn't
> > always clear IMO.
> 
> I think you got that right. I guess the entire screen for LBDAF looked
> like this _hand edited_ example:
>     Symbol: LBDAF [=n]                                      
>     Type  : boolean                                         
>     Prompt: Support for large (2TB+) block devices and files
>       Location:                                             
>     (1) -> Enable the block layer (BLOCK [=y])              
>       Defined at block/Kconfig:26                           
>       Depends on: BLOCK [=y] && !64BIT [=y]                 
> 
> In this case 64BIT is set to 'y' (otherwise LBDAF would have been 'y').

This is not correct at all. If 64BIT == 'n', LBDAF can be both 'y' or
'n'. Where's that brown paper bag again?

> This isn't a bug issue, of course, but I still can see how this can be
> confusing. Perhaps the last line should read:
>       Unmet dependency on: BLOCK [=y] && !64BIT [=y]
> 
> Would that help? Or would 
>       Depends on: BLOCK [=y] && !64BIT [=n]
> 
> (ie, print the value if "!64BIT") be clearer?
> 
> > > Not-yet-signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> 
> I'm glad I added that!
> 
> > > Today I found myself wondering why a certain Kconfig was selected.
> > > Currently menuconfig's help is of no use in complicated cases. Please
> > > look at the help of USB or CRYPTO to see what I mean.
> > > 
> > > This is a _hack_ to show what might be a better way to do this. It
> > > parses a stringified version of the reverse dependency, and not the
> > > actual reverse dependecy expression. But that was easier to cobble
> > > together.
> > > 
> > > One cool improvement would be to change to minus in front of the
> > > subexpressions to Y or M for those that actually set the symbol. Anyhow,
> > > other suggestions and feedback is welcome.
> > > 
> > >  scripts/kconfig/menu.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++--
> > >  1 file changed, 81 insertions(+), 2 deletions(-)


Paul Bolle



  reply	other threads:[~2015-01-22  8:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 23:00 [PATCH] [RFC] kconfig: menuconfig make "Selected by:" readable Paul Bolle
2015-01-22  2:23 ` Randy Dunlap
2015-01-22  8:35   ` Paul Bolle
2015-01-22  8:50     ` Paul Bolle [this message]
2015-01-22 10:33     ` Michal Marek
2015-01-22 10:47       ` Paul Bolle
2015-01-22 10:51         ` Michal Marek
2015-01-22  8:38 ` Paul Bolle
  -- strict thread matches above, loose matches on Subject: below --
2015-05-18 21:19 Petr Vorel
2015-05-18 21:28 ` Paul Bolle
2015-05-19  4:06   ` Petr Vorel

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=1421916615.13638.35.camel@x220 \
    --to=pebolle@tiscali.nl \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=rdunlap@infradead.org \
    /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