public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Max Kellermann <max.kellermann@ionos.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Xin Li <xin@zytor.com>,
	Sean Christopherson <seanjc@google.com>,
	hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	kvm@vger.kernel.org
Subject: Re: [PATCH] arch/x86/entry_fred: don't set up KVM IRQs if KVM is disabled
Date: Sat, 17 Feb 2024 01:11:58 +0100	[thread overview]
Message-ID: <87il2oar01.ffs@tglx> (raw)
In-Reply-To: <CAKPOu+9sbWwZhbexQHwqZ6nMfg6dau7oYEzzgQ5qx+JiEcdmXQ@mail.gmail.com>

On Sat, Feb 17 2024 at 00:00, Max Kellermann wrote:
> On Fri, Feb 16, 2024 at 10:45 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> #ifdeffing out the vector numbers is silly to begin with because these
>> vector numbers stay assigned to KVM whether KVM is enabled or not.
>
> There could be one non-silly use of this: if the macros are not
> defined in absence of the feature, any use of it will lead to a
> compiler error, which is good, because it may reveal certain kinds of
> bugs.

I generally agree with this sentiment, but for constants like those in
the case at hand I really draw the line.

> (Though I agree that this isn't worth the code ugliness. I prefer to
> avoid the preprocessor whenever possible. I hate how much the kernel
> uses macros instead of inline functions.)

No argument about that. I'm urging people to use inlines instead of
macros where ever possible, but there are things which can only solved
by macros.

I'm well aware that I wrote some of the more ugly ones myself. Though
the end justifies the means. If the ugly macro from hell which you
verify once safes you from the horrors of copy & pasta error hell then
they are making the code better and there are plenty of options to make
them reasonably (type) safe if done right.

Thanks,

        tglx

  reply	other threads:[~2024-02-17  0:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240215133631.136538-1-max.kellermann@ionos.com>
2024-02-15 19:55 ` [PATCH] arch/x86/entry_fred: don't set up KVM IRQs if KVM is disabled Sean Christopherson
2024-02-16  2:10   ` Xin Li
2024-02-16  6:31     ` Paolo Bonzini
2024-02-16 17:41       ` Xin Li
2024-02-16 17:47         ` Xin Li
2024-02-16 21:45       ` Thomas Gleixner
2024-02-16 23:00         ` Max Kellermann
2024-02-17  0:11           ` Thomas Gleixner [this message]
2024-02-17  9:52         ` Paolo Bonzini
2024-02-17 22:25           ` Thomas Gleixner
2024-02-16 21:46       ` Borislav Petkov
2024-02-16 22:29         ` Thomas Gleixner

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=87il2oar01.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max.kellermann@ionos.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=sfr@canb.auug.org.au \
    --cc=x86@kernel.org \
    --cc=xin@zytor.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