From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Price Date: Fri, 11 Sep 2015 12:57:13 +0100 Subject: [Cluster-devel] gfs2 on-disk headers in user space In-Reply-To: References: <1441814130-14786-1-git-send-email-andreas.gruenbacher@gmail.com> <1441814130-14786-2-git-send-email-andreas.gruenbacher@gmail.com> <55F05E01.3030205@redhat.com> <55F2B0BA.3090109@redhat.com> <55F2BAF8.408@redhat.com> Message-ID: <55F2C199.40302@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 11/09/15 12:40, Andreas Gr?nbacher wrote: > 2015-09-11 13:28 GMT+02:00 Andrew Price : >> That makes sense to me. I assume we would remove the #include >> from gfs2_ondisk.h and replace it with our own user space >> types header. I'm worried about clashes using the kernel type names though, >> so we might need to process the header somehow to change them. > > We could substitute the __beX types with uintX_t on import; also we > could warn if the system header exists but in a different version than > what's "cached" in gfs2-utils. That sounds like a good direction to go, but it would be good to keep big-endian types separate from native-endian types with __bitwise so that mixing endianness will be picked up by a static checker. I believe that was Steve's main concern last time we discussed this. Andy