From: Mauro Carvalho Chehab [mailto:mchehab+huawei@kernel.org] Sent: Wednesday, July 28, 2021 3:08 PM Em Wed, 28 Jul 2021 11:45:02 +0000 Roberto Sassu roberto.sassu@huawei.com escreveu:
From: Mauro Carvalho Chehab [mailto:mchehab+huawei@kernel.org] Sent: Wednesday, July 28, 2021 1:31 PM Em Mon, 26 Jul 2021 18:36:50 +0200 Roberto Sassu roberto.sassu@huawei.com escreveu:
+struct compact_list_hdr {
- __u8 version;
- __u8 _reserved;
- __le16 type;
- __le16 modifiers;
- __le16 algo;
- __le32 count;
- __le32 datalen;
+} __packed; +#endif /*_UAPI__LINUX_DIGLIM_H*/
Besides Greg's notes, I'm wondering why to enforce a particular endness here. I mean, this is uAPI. I would expect it to use the CPU endianness instead, in order to avoid uneeded conversions.
Also Greg had the same concern. I hoped the Lifecycle section clarified the fact that digest lists are generated by software vendors not the local system. Should I add something more in the documentation?
It shouldn't matter what kind of endness software vendors use on userspace (either CPU or a fixed endiannes - either LE or BE).
I mean, I won't doubt that some package tools use LE while others would use BE. At some point, this needs to be converted to CPU endiannes.
If you let digest list generators decide the endianness, probably it is necessary to also add the endianness information in the structure. Otherwise, the kernel wouldn't know what to do.
If the kernel knows that the digest list is always in little endian, it simply calls le32_to_cpu().
IMO, the best would be to isolate whatever RPM/DEB/... endianness is used on userspace from what the Kernel will use internally.
This is a different case. The conversion happens if the digest list is not in native format. The kernel can also parse an untouched digest list if it is in native format.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Li Jian, Shi Yanli
Just my 2 cents.
Regards, Mauro