On Sun, Nov 21, 2021 at 09:20:09AM +1100, Dave Chinner wrote: > On Sat, Nov 20, 2021 at 09:15:48AM -0800, Darrick J. Wong wrote: > > On Sat, Nov 20, 2021 at 08:32:40AM +0100, Helmut Grohne wrote: > > > Hi Dave, > > > > > > On Sat, Nov 20, 2021 at 10:11:05AM +1100, Dave Chinner wrote: > > > > I don't get it. The crcselftest does not use liburcu in > > > > any way, nor does it try to link against liburcu, so it should not > > > > fail because other parts of xfsprogs use liburcu. > > > > > > > > What's the build error that occurs? > > > > > > As the build log shows, that's not technically accurate. You can find > > > logs of test builds for various architecture combinations at > > > http://crossqa.debian.net/src/xfsprogs. This is also available as a link > > > called "cross" in https://tracker.debian.org/xfsprogs. > > > > > > The relevant part is: > > > | [TEST] CRC32 > > > | In file included from crc32.c:35: > > > | ../include/platform_defs.h:27:10: fatal error: urcu.h: No such file or directory > > > | 27 | #include <urcu.h> > > > | | ^~~~~~~~ > > > | compilation terminated. > > > > > > I failed to figure a good way of dropping either include directive. > > > > > > > We need to fix the generic cross-build problem in the xfsprogs code, > > > > not slap a distro-specific build band-aid over it. > > > > > > I fully agree with this in principle. However, when I fail to find that > > > upstreamable solution, I try to at least provide a Debian-specific > > > solution to iterate from. > > > > > > Can you propose a way to drop either #include? > > > > Frankly I don't really see the value in crc32selftest when cross > > compiling -- sure, the crc32c code works correctly on the build host, > > but that proves nothing about the (cross-)built binaries that end up in > > the package. > > Yup, that's pretty much what I was getting at. > > > The selftest code is modular enough that it's included in xfs_io and it > > seems to run in under 500us even on my ancient raspberry pi 3b+ > > downclocked to 600mhz. Why don't we just add it to mkfs and repair? > > Those tools shouldn't be run all that frequently, and now we'll know > > immediately if crc32c is broken on a user's system. > > > > Then we don't need the build-time selftest at all. > > Sounds reasonable, my only concern is what do users do when > xfs-repair fails the self test and they need to fix their > filesystem? Find a system with a non-broken CPU, or complain to their support rep or the upstream mailing list. I'd rather they do that than let repair erroneously obliterate all the metadata with incorrect crc validation, or write garbage out that fails to mount immediately after. --D > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
