All of lore.kernel.org
 help / color / mirror / Atom feed
From: helgaas at kernel.org (Bjorn Helgaas)
Subject: [Linux-kernel-mentees] [PATCH] lspci: Make output for empty range behind a bridge consistent
Date: Wed, 8 May 2019 08:40:36 -0500	[thread overview]
Message-ID: <20190508134036.GA220289@google.com> (raw)
In-Reply-To: <20190508052118.21796-1-skunberg.kelsey@gmail.com>

Hi Kelsey,

On Tue, May 07, 2019 at 11:21:18PM -0600, Kelsey Skunberg wrote:
> When a range behind a bridge is empty, '[empty]' will be displayed
> after the prefix. Removing option to display 'None' for consistency.

1) I don't think Martin enforces this for pciutils, but for the kernel
we prefer to use imperative mood in the commit log as you did in the
subject, e.g., say "Remove" instead of "Removing".

2) The commit log doesn't quite make it clear what the purpose of this
is.  I *think* it's so that "lspci -vv" and "lspci -vvv" both use the
same text to describe a disabled window.  Saying that explicitly,
along with sample output, would help, e.g., the current output is:

  Memory behind bridge: None                          # lspci -vv
  Memory behind bridge: 00200000-001fffff [empty]     # lspci -vvv

and you're changing it so both -vv and -vvv use "[empty]":

  Memory behind bridge: [empty]                       # lspci -vv
  Memory behind bridge: 00200000-001fffff [empty]     # lspci -vvv

Personally I think that if we make them both the same, using "[None]"
instead of "[empty]" would read better, at least for -vv.

But "[empty]" does make good sense for the -vvv case, so maybe the
existing code is better even with the inconsistency.  I guess that's
up to Martin.

> Using -vvv will include full range addresses between prefix and '[empty]'.
> 
> show_range() is only called when verbose (-v). Code checking for
> 'not verbose' is not needed.

Nice simplification!  I would split this into a separate patch because
it's not logically related to changing the text and it will make both
patches easier to read.  Also, it would make it easy for Martin to
choose whether he wants to apply one, both, or neither.

If/when you repost, be sure to add "[PATCH v2]" in the subject and,
since there's more than one patch, ideally, add a "[PATCH v2 0/n]"
cover letter, with each patch as a response to the cover letter.  That
helps keep them all together.

> Signed-off-by: Kelsey Skunberg <skunberg.kelsey at gmail.com>
> ---
>  lspci.c | 22 +++++++---------------
>  1 file changed, 7 insertions(+), 15 deletions(-)

Pay close attention to the diff.  In this case you accidentally added
a whitespace error (space at end of line).  Other ones to avoid are
space followed by tab and blank lines at end of file.  Some projects
avoid tabs completely (using spaces instead); you just have to notice
the previous practice in the file and follow that.

> diff --git a/lspci.c b/lspci.c
> index d63b6d0..65cbde9 100644
> --- a/lspci.c
> +++ b/lspci.c
> @@ -375,23 +375,15 @@ show_size(u64 x)
>  
>  static void
>  show_range(char *prefix, u64 base, u64 limit, int is_64bit)
> -{

Here's the spurious whitespace change.

> -  if (base > limit)
> +{ 
> +  printf("%s:", prefix);
> +  if (base <= limit || verbose > 2)

I like how your new code only uses "base <= limit" instead of how the
previous code used both "base <= limit" and "base > limit".  They're
basically testing for the same thing, so it was a small mental burden
to have to recognize them as related.

>      {
> -      if (!verbose)
> -	return;
> -      else if (verbose < 3)
> -	{
> -	  printf("%s: None\n", prefix);
> -	  return;
> -	}
> +      if (is_64bit)
> +        printf(" %016" PCI_U64_FMT_X "-%016" PCI_U64_FMT_X, base, limit);
> +      else
> +        printf(" %08x-%08x", (unsigned) base, (unsigned) limit);
>      }
> -
> -  printf("%s: ", prefix);
> -  if (is_64bit)
> -    printf("%016" PCI_U64_FMT_X "-%016" PCI_U64_FMT_X, base, limit);
> -  else
> -    printf("%08x-%08x", (unsigned) base, (unsigned) limit);
>    if (base <= limit)
>      show_size(limit - base + 1);
>    else
> -- 
> 2.20.1
> 

WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
Subject: [Linux-kernel-mentees] [PATCH] lspci: Make output for empty range behind a bridge consistent
Date: Wed, 8 May 2019 08:40:36 -0500	[thread overview]
Message-ID: <20190508134036.GA220289@google.com> (raw)
Message-ID: <20190508134036.ZW95dOHbm6jiPDPmyLo4wQIwIZjiNQn78Xvx0UGsH3A@z> (raw)
In-Reply-To: <20190508052118.21796-1-skunberg.kelsey@gmail.com>

Hi Kelsey,

On Tue, May 07, 2019 at 11:21:18PM -0600, Kelsey Skunberg wrote:
> When a range behind a bridge is empty, '[empty]' will be displayed
> after the prefix. Removing option to display 'None' for consistency.

1) I don't think Martin enforces this for pciutils, but for the kernel
we prefer to use imperative mood in the commit log as you did in the
subject, e.g., say "Remove" instead of "Removing".

2) The commit log doesn't quite make it clear what the purpose of this
is.  I *think* it's so that "lspci -vv" and "lspci -vvv" both use the
same text to describe a disabled window.  Saying that explicitly,
along with sample output, would help, e.g., the current output is:

  Memory behind bridge: None                          # lspci -vv
  Memory behind bridge: 00200000-001fffff [empty]     # lspci -vvv

and you're changing it so both -vv and -vvv use "[empty]":

  Memory behind bridge: [empty]                       # lspci -vv
  Memory behind bridge: 00200000-001fffff [empty]     # lspci -vvv

Personally I think that if we make them both the same, using "[None]"
instead of "[empty]" would read better, at least for -vv.

But "[empty]" does make good sense for the -vvv case, so maybe the
existing code is better even with the inconsistency.  I guess that's
up to Martin.

> Using -vvv will include full range addresses between prefix and '[empty]'.
> 
> show_range() is only called when verbose (-v). Code checking for
> 'not verbose' is not needed.

Nice simplification!  I would split this into a separate patch because
it's not logically related to changing the text and it will make both
patches easier to read.  Also, it would make it easy for Martin to
choose whether he wants to apply one, both, or neither.

If/when you repost, be sure to add "[PATCH v2]" in the subject and,
since there's more than one patch, ideally, add a "[PATCH v2 0/n]"
cover letter, with each patch as a response to the cover letter.  That
helps keep them all together.

> Signed-off-by: Kelsey Skunberg <skunberg.kelsey at gmail.com>
> ---
>  lspci.c | 22 +++++++---------------
>  1 file changed, 7 insertions(+), 15 deletions(-)

Pay close attention to the diff.  In this case you accidentally added
a whitespace error (space at end of line).  Other ones to avoid are
space followed by tab and blank lines at end of file.  Some projects
avoid tabs completely (using spaces instead); you just have to notice
the previous practice in the file and follow that.

> diff --git a/lspci.c b/lspci.c
> index d63b6d0..65cbde9 100644
> --- a/lspci.c
> +++ b/lspci.c
> @@ -375,23 +375,15 @@ show_size(u64 x)
>  
>  static void
>  show_range(char *prefix, u64 base, u64 limit, int is_64bit)
> -{

Here's the spurious whitespace change.

> -  if (base > limit)
> +{ 
> +  printf("%s:", prefix);
> +  if (base <= limit || verbose > 2)

I like how your new code only uses "base <= limit" instead of how the
previous code used both "base <= limit" and "base > limit".  They're
basically testing for the same thing, so it was a small mental burden
to have to recognize them as related.

>      {
> -      if (!verbose)
> -	return;
> -      else if (verbose < 3)
> -	{
> -	  printf("%s: None\n", prefix);
> -	  return;
> -	}
> +      if (is_64bit)
> +        printf(" %016" PCI_U64_FMT_X "-%016" PCI_U64_FMT_X, base, limit);
> +      else
> +        printf(" %08x-%08x", (unsigned) base, (unsigned) limit);
>      }
> -
> -  printf("%s: ", prefix);
> -  if (is_64bit)
> -    printf("%016" PCI_U64_FMT_X "-%016" PCI_U64_FMT_X, base, limit);
> -  else
> -    printf("%08x-%08x", (unsigned) base, (unsigned) limit);
>    if (base <= limit)
>      show_size(limit - base + 1);
>    else
> -- 
> 2.20.1
> 

  reply	other threads:[~2019-05-08 13:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08  5:21 [Linux-kernel-mentees] [PATCH] lspci: Make output for empty range behind a bridge consistent skunberg.kelsey
2019-05-08  5:21 ` Kelsey Skunberg
2019-05-08 13:40 ` helgaas [this message]
2019-05-08 13:40   ` Bjorn Helgaas
2019-05-09  5:35   ` skunberg.kelsey
2019-05-09  5:35     ` Kelsey Skunberg
2019-05-09 12:42     ` helgaas
2019-05-09 12:42       ` Bjorn Helgaas

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=20190508134036.GA220289@google.com \
    --to=unknown@example.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.