Hi Sage,

> I think the cleanest thing is to s/__le/ceph_le/ everywhere *except*
> msgr.h, rados.h, and ceph_fs.h.  It seems like what happened was we mostly
> forgot to always use the ceph_ variant after 2010.
>
> That should resolve the issue, right?

That's what we've tried to do, and it does indeed make work Ceph a lot
better on IBM Z (still some issues, but probably unrelated).  Once we've
gotten a bit farther with testing, we can certainly send patches to
that effect.


However, where I'm still unsure is that there appear to be a number of
files that e.g. just #include "ceph_fs.h" directly, without going
through the re-define in types.h ...

Now maybe this doesn't matter because none of those places actually
use any of the structs that use __le32 from those headers, but that
seems hard to verify (and a bit fragile ...).

Would the correct fix for this be to replace the direct includes
with includes of types.h?  Or should those headers be changed to be
more self-contained and always define __le32 themselves when built
in user space (but I'm not quite sure how to do that without
conflicting with the __le32 definition in linux/types.h ...)?


In any case, it would be really good to find a way to have those
rules (e.g. never use __le32, never include ceph_fs.h directly)
automatically enforced at build time, to avoid any reoccurance
of the problem with future code changes.


Thanks for your quick reply!

Bye,
Ulrich