From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] libgfs2: Import gfs2_ondisk.h
Date: Fri, 8 Nov 2019 09:50:00 +0000 [thread overview]
Message-ID: <8967ad5b-2a4c-ddba-2386-fff7533458fc@redhat.com> (raw)
In-Reply-To: <20190409123510.GA27246@infradead.org>
Revisiting this...
On 09/04/2019 13:35, Christoph Hellwig wrote:
> On Tue, Apr 09, 2019 at 01:21:23PM +0100, Steven Whitehouse wrote:
>> Those conversion functions are not sensible, thats why we got rid of them
>> from the kernel code. It is better to have a set of types that have the
>> endianess specified so that we can use sparse. Compile time checking is
>> always a good plan where it is possible.
>
> Yeah. And <linux/types.h> vs inttypes.h is no argument either,
> you can define the __be types based on the inttypes.h types (which
> really are stdint.h ones anyway).
Linux's __be* type definitions are pulled in by standard headers (e.g.
sys/stat.h via bits/statx.h -> linux/stat.h -> linux/types.h) so they
can't be redefined in terms of stdint.h types, unfortunately. Even if
that did work it could easily be broken outside of our control in the
future, so that's another reason to leave the __be* types alone.
So I think the best we can do is define some new bitwise-annotated types
based on stdint.h and change the imported gfs2_ondisk.h to use them.
Andy
next prev parent reply other threads:[~2019-11-08 9:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 9:41 [Cluster-devel] [PATCH] libgfs2: Import gfs2_ondisk.h Andrew Price
2019-04-09 12:03 ` Christoph Hellwig
2019-04-09 12:18 ` Andrew Price
2019-04-09 12:21 ` Steven Whitehouse
2019-04-09 12:35 ` Christoph Hellwig
2019-11-08 9:50 ` Andrew Price [this message]
2019-04-09 12:48 ` Andrew Price
2019-04-09 13:03 ` Steven Whitehouse
2019-04-09 13:14 ` Andrew Price
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=8967ad5b-2a4c-ddba-2386-fff7533458fc@redhat.com \
--to=anprice@redhat.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).