1. the ioctl ID encoding space is fully used already -- all the bits
in an ioctl ID are meaningful, so there'd be nowhere to pack the new
info;
What does this mean? So we can't create new ioctl op and args for drm
with the same value in Linux?
2. where would the received pointer point? -- in other words, where
...
It is very possible to implement this behavior on top of MIG routines.
But it is way too complex to try and support this in ioctls. We would
need to somehow encode where in the structure the size and the pointer
are... No, this just can't happen.
In conclusion, there is no way to do things like using a pointer to pass
data pointed by it in Mach. I can understand this is rooted in Mach
design. This does create problems of mimicking API in Linux to reuse a
lot of high-level things. At least for drm, most APIs of drm in Linux
are implemented by passing data with pointer with ioctl. libdrm relies
on this, and then mesa relies on libdrm, and OpenGL and Vulkan apps rely
on mesa.
But, Mach is Mach, Hurd is Hurd.
How do I solve this? Can we extend MiG to be smarter about nested
structures when
data needs to be transferred within structs? How do we solve the
ordering problem of
the *_length parameter?
At least for the calls that have more complex behavior wrt memory (and
not just passing bundles of integers), don't try to make them into
ioctls, make them real full MIG routines, and use them as such from
the client side. Is it just drm_version? If so, perhaps it could just
always return some hardcoded values client-side, without making any
RPCs at all.
It is not only drm_version but a lot of structs.
All in all, we have to patch on libdrm, anyway. How about we make a
patch in libdrm? Wrap ioctl with real implementation for Mach and Hurd
(by passing real data in RPC instead of nonsense pointers) and preserve
the behavior that libdrm expects. And at the same time, solve the
problem of using particular ioctl op and args that is conflict with
existing value. Or do you have some ideas on this?
