On Thu, 18 Jul 2019, Ulrich Weigand wrote: > 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. Great, thanks! > 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. Yeah, agree. I think the best option would be to make those headers have a bit at the top that ensure thigns are correctly defined for userspace. We don't want that block to leak into the kernel tree, but it's easy enough to ignore a single block of code; much harder to keep them in sync if we were to, say, s/__le32/ceph_le32/ in the headers. sage _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
