-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests: Assert that byte-order is swapped on LE but not BE CPUs #1393
Conversation
Closes: ostreedev#1392 Signed-off-by: Simon McVittie <smcv@collabora.com>
The byte order stuff is a mess; for core ostree we standardized on BE but that doesn't (necessarily) cover user-added metadata. We also screwed up on static deltas but that's mostly fixed now. |
Nice, thank you very much! Keeping the test suite running is very much appreciated! I have a half-done WIP to run the ostree tests in the new Fedora test standard and it will greatly benefit from these fixes. Thanks again! |
Sure, but if I put 42 in, shouldn't I get 42 out, without needing to know or care whether ostree stores it in BE, LE, JSON or hieroglyphs? |
The problem is it's just one big variant...so we started doing byteswap-if-necessary for the core metadata like the timestamp, but that necessarily swaps the user metadata too. We probably could teach |
I wish we had more of it, but unfortunately Debian mostly provides build-time testing ( The autopkgtest infrastructure runs GNOME-style installed-tests, but I can currently only do that on x86_64 (LXC on official infrastructure and qemu on my laptop) - there used to be arm64 LXC workers but those are currently unavailable. |
☀️ Test successful - status-atomicjenkins |
It certainly feels as though something not right if (I actually think the existence of Adding new, parallel APIs and deprecating the current ones might be a proportionate response. It's unfortunate that the serialized data structure on disk doesn't carry an indication of how it should be interpreted, but perhaps it isn't too late for rpm-ostree to start writing out metadata in a consistent endianness, with a flag to say it has done so? |
Sorry, meant to follow up earlier. Yes...new API could make sense. And a consistent endianness marker. |
Closes: #1392
Signed-off-by: Simon McVittie smcv@collabora.com
I'm still not sure I understand why the "obvious" code path through
commit --add-metadata
andshow
byteswaps the metadata - I would have expected that ostree would either define the metadata to be stored in a standardized byte order (in which case machines of the other byte order should byteswap during commit and byteswap back during show), or define the metadata to be stored in the host byte order of the machine that is expected to consume the tree, or store a byte-order indicator. But this does seem to work on both x86_64 (LE) and s390x (BE).