All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: do not shadow apic global definition
Date: Fri, 29 Jul 2022 17:48:53 +0000	[thread overview]
Message-ID: <YuQdhaUi0ur4l/zb@google.com> (raw)
In-Reply-To: <20220729084533.54500-1-mailhol.vincent@wanadoo.fr>

On Fri, Jul 29, 2022, Vincent Mailhol wrote:
> arch/x86/include/asm/apic.h declares a global variable named `apic'.
> 
> Many function arguments from arch/x86/kvm/lapic.h also uses the same
> name and thus shadow the global declaration. For each case of
> shadowing, rename the function argument from `apic' to `lapic'.
> 
> This patch silences below -Wshadow warnings:

This is just the tip of the iceberg, nearly every KVM x86 .c file has at least one
"apic" variable.  arch/x86/kvm/lapic.c alone has nearly 100.  If this were the very
last step before a kernel-wide (or even KVM-wide) enabling of -Wshadow then maybe
it would be worth doing, but as it stands IMO it's unnecesary churn.

What I would really love is to not have the global (and exported!) "apic", but
properly solving that, i.e. not just a rename, would require a significant rework.

  reply	other threads:[~2022-07-29 17:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29  8:45 [PATCH] KVM: x86: do not shadow apic global definition Vincent Mailhol
2022-07-29 17:48 ` Sean Christopherson [this message]
2022-07-30  4:15   ` Vincent MAILHOL
2022-08-02 20:12     ` Sean Christopherson

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=YuQdhaUi0ur4l/zb@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 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.