On 09/04/2019 13:21, Steven Whitehouse wrote:
Hi,
On 09/04/2019 13:18, Andrew Price wrote:
On 09/04/2019 13:03, Christoph Hellwig wrote:
On Tue, Apr 09, 2019 at 10:41:53AM +0100, Andrew Price wrote:
Give gfs2-utils its own copy of gfs2_ondisk.h which uses userspace
types. This allows us to always support the latest ondisk structures
and
obsoletes a lot of #ifdef GFS2_HAS_<FEATURE> blocks and configure.ac
checks.
gfs2_ondisk.h was changed simply by search-and-replace of the kernel
int
types with the uintN_t, i.e.:
:%s/__u\(8\|16\|32\|64\)/uint\1_t/g
:%s/__be\(64\|32\|16\|8\)/uint\1_t/g
and the linux/types.h include replaced with stdint.h
Why?
Because I'd like to be able to build gfs2-utils on FreeBSD one day.
Plus we get the handy stuff in inttypes.h to use, Linux doesn't have
that.
At least the be types give you really useful type checking with
sparse, which can be trivially wired up in userspace as well.
If you mean the bitwise annotations that only sparse checks, we're
fairly safe in gfs2-utils in that anything represented by a struct is
going to have been parsed through one of the libgfs2/ondisk.c
functions so will be the right endianness. I run sparse over this code
very rarely anyway.
Those conversion functions are not sensible, thats why we got rid of
them from the kernel code.
Is it the functions that aren't sensible or the use of the gfs2_ondisk.h
structs as the containers for the native endian data? I'm not sure I get
why the kernel functions like gfs2_dinode_in() are considered sensible
and gfs2-utils' gfs2_dinode_in(), which does a similar thing but with a
different struct, isn't sensible.
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.
Okay, I'll add back the bitwise annotations through typedefs to stdint.h
types in a new header but I don't want to name it linux/types.h to avoid
picking up the wrong one, so I'll just change that #include in
gfs2_ondisk.h.
Andy
