-
Notifications
You must be signed in to change notification settings - Fork 363
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
Add support for little-endian byte order representation. #75
base: master
Are you sure you want to change the base?
Conversation
Although RFC4122 recommends network byte order for all fields, the PC industry (including the ACPI, UEFI, SMBIOS and Microsoft specifications) has consistently used little-endian byte encoding for the first three fields: time_low, time_mid, time_hi_and_version. Example from SMBIOS spec, section 7.2.1 System - UUID The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented as: 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf
So this means the version cannot be determined since they moved the version field. Sounds like Microsoft. This isn't the first standard that they have messed up for everyone else. I am not sure how the unmarshaling will get called int this change. I could see a function that swaps between a compliant UUID and a non-compliant one. To make this work with any of encoding packages that use the Unmarshaler interface I think you would need a whole new type that modifies both the marshal/unmarshal methods as well as parsing bytes. This will deserve some more thought and discussion. It would also deserve some tests :-) |
Yes, as far as I understand the situation, there is no way to determine what byte order is used in the UUID binary representation. One "must know in advance" what byte order is used for encoding.
Let me explain the situation as I see it. Let's take a look on example. Imagine a device produced by a hardware vendor. Each vendor has its own UUID, embedded into produced device. Let's say we'd like to print "human-readable name" of the vendor.
In our case UUID inside the Let's introduce another function,
and the whole piece of code will run correctly.
Yes, I've introduced top-level function
which is insiped by
and appropriate marshaling functions:
which are inspired by
respectively. These new functions understand little-endian byte encoding and how to Marshal/Unmarshal binary data.
Can you, please, elaborate this item a little bit, I am not sure what exacly is meant here. Is it really so complicated? And how already exisiting functions, such as Also I am not sure about whole new type, because it is still the same UUID with the same logic/idea. The only thing different is byte order in UUID's binary representation.
Yes, sure, that's why I am opening the discussion with initial PR for little-endian encoding support.
Insipired by
Yep :-) |
These really are two different types because they have different binary representations and they are not comparable to each other without converting from one to another. Also, encoders, such as encoding/json, use interfaces as described in encoding to know how to encode/decode values. Since there are interfaces they must have those exact names. The only way to get JSON to unmarshal an SMBIOS UUID (as opposed to regular UUID) is to have a new type. It does not need all the functions provided by the standard UUID package and can easily be written in terms of the regular uuid package:
|
I wrote up a working example of what I suggested above, it is included below. Would this concept work for you? In your structures who are serialized to the DSP0134 format you would use the
|
Hey, I made and example package: github.com/pborman/dsp0134 |
Thanks a lot for the detailed explanation, I understand now that initial approach was incorrect. Little-endian UUID has to comply to interfaces from
Thank you very much for the package, I'll try tomorrow, sorry for the delay. |
Did this work? I am wondering if it is worth making into a supported package or not. I am thinking a sub package of this UUID package. |
Although RFC4122 recommends network byte order for all fields, the PC industry (including the ACPI, UEFI, SMBIOS and Microsoft specifications) has consistently used little-endian byte encoding for the first three fields: time_low, time_mid, time_hi_and_version.
Example from SMBIOS spec, section 7.2.1 System - UUID
The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented as: 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf