On 01/11/2023 18:31, Carsten Haitzler wrote:
_IOC(_IOC_READ|_IOC_WRITE, MMC_BLOCK_MAJOR, 0, 64)) - compat structs
are
not defined in uapi headers, so we cannot use them. Opinions very
Well my structs are beginning to look like:
struct drm_mode_obj_get_properties { #ifdef __CHERI__ __kernel_uintptr_t props_ptr; __kernel_uintptr_t prop_values_ptr;
__kernel_uintptr_t is specifically intended to be __u64 in !PCuABI, so the #ifdef'ing makes no difference at all. Also worth noting __CHERI__ is not about the ABI, it's about whether we are compiling with CHERI support - i.e. it's defined in both hybrid and purecap. __CHERI_PURE_CAPABILITY__ is the one that is defined in purecap only (but of course cannot be used in uapi headers since the kernel itself is not purecap).
Is there any struct with pointers represented as unsigned long? If that's the case, we'll have to define a new type that is equivalent to uintptr_t from a userspace perspective... That's where we may have made a mistake in naming __kernel_uintptr_t :/
#else __u64 props_ptr; __u64 prop_values_ptr; #endif __u32 count_props; __u32 obj_id; __u32 obj_type; };
So same struct - keep the previous compat behavior but CHERI gets the new type sizes. The drm folk seems to have oscillated between unsigned longs and __u64's being "good enough for pointers from userspace". It's not consistent, but it is what it is. This above is the kernel header. My copy of the same structs in libdrm:
Is there a particular reason why we couldn't directly use/import the kernel headers into libdrm?
[...]
Yes - I know it's "32". It lies. drm infra has already accepted that "compat" == named 32bit by convention within its tree but for us compat == 64bit, so I'm just following the convention.
That's fine, we're trying to have reasonably minimal diffs so lying on compat32/compat64 is acceptable (and we've already done it in other subsystems).
Now, coming back to the original topic ;) How do you handle command definitions, in such a way that the struct gets larger in PCuABI, but without the command value changing? Taking the struct above as example, the value of DRM_IOCTL_MODE_OBJ_GETPROPERTIES is going to change if its definition remains unchanged, and that's something we want to avoid.
Kevin