From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Willy Tarreau <w@1wt.eu>
Cc: "Thomas Weißschuh" <linux@weissschuh.net>,
"Arnd Bergmann" <arnd@arndb.de>,
linux-kernel@vger.kernel.org, "Zhangjin Wu" <falcon@tinylab.org>,
"Yuan Tan" <tanyuan@tinylab.org>
Subject: Re: [PATCH RFC] misc/pvpanic: add support for normal shutdowns
Date: Sat, 4 Nov 2023 18:07:21 +0100 [thread overview]
Message-ID: <2023110418-unreached-smith-5625@gregkh> (raw)
In-Reply-To: <ZUZNkpEiHHWsmZhT@1wt.eu>
On Sat, Nov 04, 2023 at 02:56:34PM +0100, Willy Tarreau wrote:
> On Sat, Nov 04, 2023 at 02:53:37PM +0100, Thomas Weißschuh wrote:
> > > > The real reason probably doesn't matter today as the header propably
> > > > can't be dropped from Linux anyways for compatibility reasons.
> > > >
> > > > > And if they need to be here, why not use the proper BIT() macro for it?
> > > >
> > > > This was for uniformity with the existing code.
> > > > I can send a (standalone?) patch to fix it up.
> > >
> > > If we keep it, sure, that would be nice. But let's try to drop it if
> > > possible :)
> >
> > It will break the mentioned scripts/update-linux-headers.sh from qemu.
> >
> >
> > Note:
> >
> > BIT() is part of include/vdso/bits.h which is not part of the
> > uapi. How is it supposed to work?
> > Some other uapi header also use BIT() but that seems to work by accident
> > as the users have the macro defined themselves.
>
> Be careful here, we don't want to expose this kernel macro to userland,
> it would break programs that define their own (possibly different) BIT
> macro. BIT() is used in kernel headers but we should not presume that
> it is available from userland.
It's already there :(
I thought we had a uapi-safe version somewhere, but I can't seem to find
it anymore, so I don't remember what it is called.
thanks,
greg k-h
next prev parent reply other threads:[~2023-11-04 17:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-04 11:29 [PATCH RFC] misc/pvpanic: add support for normal shutdowns Thomas Weißschuh
2023-11-04 13:05 ` Greg Kroah-Hartman
2023-11-04 13:16 ` Thomas Weißschuh
2023-11-04 13:28 ` Greg Kroah-Hartman
2023-11-04 13:53 ` Thomas Weißschuh
2023-11-04 13:56 ` Willy Tarreau
2023-11-04 17:07 ` Greg Kroah-Hartman [this message]
2023-11-04 17:32 ` Thomas Weißschuh
2023-11-05 6:59 ` Willy Tarreau
2024-02-13 10:41 ` Michael S. Tsirkin
2024-02-21 17:18 ` Thomas Weißschuh
2024-02-28 6:48 ` Thomas Weißschuh
2024-02-28 7:02 ` Arnd Bergmann
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=2023110418-unreached-smith-5625@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=falcon@tinylab.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=tanyuan@tinylab.org \
--cc=w@1wt.eu \
/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.