From: Joe Perches <joe@perches.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 4/4] CPER: Remove unnecessary use of user-space types
Date: Mon, 25 Mar 2019 12:13:15 -0700 [thread overview]
Message-ID: <1542313a5e6de85b2991e63eab75f3a94a0eb30f.camel@perches.com> (raw)
In-Reply-To: <20190325182608.GS251185@google.com>
On Mon, 2019-03-25 at 13:26 -0500, Bjorn Helgaas wrote:
> On Mon, Mar 25, 2019 at 01:14:25PM -0500, helgaas@kernel.org wrote:
> > From: Bjorn Helgaas <bhelgaas@google.com>
> >
> > "__u32" and similar types are intended for things exported to user-space,
> > including structs used in ioctls; see include/uapi/asm-generic/int-l64.h.
> >
> > They are not needed for the CPER struct definitions, which not exported to
> > user-space and not used in ioctls. Replace them with the typical "u32" and
> > similar types. No functional change intended.
[]
> I *think* the conclusion there was that this sort of change makes
> sense, but I want to make sure. If it does make sense, I'm surprised
> at how much stuff in include/linux/ still uses __u32 when it doesn't
> appear to need it.
It is a fairly large number.
$ git grep -w -P '__[us](?:8|16|32|64)' include/linux/ | wc -l
2318
It's a rather large number of patches though to make all the
actual function definitions match the declarations that are
spread around the kernel sources as well.
Whatever struct member uses of possible temporary assignments
could also be changed to match.
Perhaps it's a lot of churn for relatively little benefit
though I do find __ prefixes unsightly when unnecessary.
A gradual conversion would eventually help isolate uapi uses
in the kernel sources.
next prev parent reply other threads:[~2019-03-25 19:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 18:14 [PATCH 0/4] PCI, CPER: Trivial cleanups helgaas
2019-03-25 18:14 ` [PATCH 1/4] PCI: Cleanup register definition width and whitespace helgaas
2019-03-25 18:14 ` [PATCH 2/4] PCI: Fix comment typos helgaas
2019-03-30 17:56 ` Mukesh Ojha
2019-04-01 13:43 ` Bjorn Helgaas
2019-03-25 18:14 ` [PATCH 3/4] CPER: Add UEFI spec references helgaas
2019-03-25 18:14 ` [PATCH 4/4] CPER: Remove unnecessary use of user-space types helgaas
2019-03-25 18:26 ` Bjorn Helgaas
2019-03-25 19:13 ` Joe Perches [this message]
2019-03-25 19:56 ` Greg Kroah-Hartman
2019-03-30 12:52 ` Masahiro Yamada
2019-03-27 13:56 ` [PATCH 0/4] PCI, CPER: Trivial cleanups 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=1542313a5e6de85b2991e63eab75f3a94a0eb30f.camel@perches.com \
--to=joe@perches.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yamada.masahiro@socionext.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;
as well as URLs for NNTP newsgroup(s).