Re: [RFC: drm server] limitations of MiG for ioctls

[Sergey Bugaev]

On Tue, Nov 5, 2024 at 10:16 AM Yuqian Yang <crupest@crupest.life> wrote:
> > 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?

It has to do with how ioctls are implemented on the Hurd (in glibc). I
went into some more details about this in the other thread (about
RTC), but basically since glibc doesn't want to statically contain
knowledge of all the possible ioctls and their argument types, instead
the info about argument types of an ioctl is encoded directly into the
ioctl number (aka ID, op). So the IDs are not random and contain info
about the ioctl they identify; and this means that you cannot just
pick any (otherwise unused) ID for an ioctl -- the ID has to match the
ioctl's arguments.

And one of the reasons that we can't extend the ioctl mechanism to
support the more advanced operations wrt memory buffers that Damien
needs is that for that, we would have to come up with a way to encode
this new info into the ioctl ID as well, but we cannot, since all the
individual bits of the 32-bit ID type are already used.

But also see what Samuel says about _HURD_HANDLE_IOCTL -- I completely
forgot about that.

> 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?

I have not looked into libdrm so this might be entirely wrong (or
naive, as azert says), but I was imagining libdrm basically wraps the
ioctls into C functions, like

int drmFooBar(int fd, int a, int b) {
    struct drm_foo_bar arg { a, b };
    return ioctl(fd, DRM_FOO_BAR, &arg);
}

and we'd instead make it into

#ifndef __GNU__
the above...
#else
int drmFooBar(int fd, int a, int b) {
    return HURD_DPORT_USE(fd, drm_foo_bar(port, a, b));
}
#endif

or more likely these would be in separate files rather than ifdef'ed,
but you get the idea.

If that's not what libdrm does? or is it unfeasible to have separate
versions for Linux and Hurd like that?

Sergey