On Mon, Nov 4, 2024 at 2:44 AM Damien Zammit via Bug reports for the GNU Hurd <
bug-hurd@gnu.org> wrote:
Hi,
I am currently attempting to implement a drm server to provide
a way to use libdrm with multiboot framebuffer exposed by new device(mbinfo).
I am running into a problem that I am unable to implement a compatible
ioctl api because of the layout of the structures.
I would prefer to reuse the same api as drm ioctls rather than implement
a modified version using traditional RPCs with many arguments.
This is because libdrm would need to be modified substantially and I don't want
to clutter the client with more parameters and conditional code.
The main problem is that a few of the OUT ioctls expect the server to copy data
through the RPC, and MiG is confused by nested structs, it doesn't seem to
support something like:
type drm_version_t = struct {
int foo;
int bar_length;
data_t bar;
};
Yes. MiG only supports fixed-sized structs and doesn't know how to deal with members that are pointers. This would be a significant change.
You _can_ specify individual parameters in the routine like so:
routine drm_version (
port: drm_t;
foo: int;
out bar: data_t SCP);
but then the bar_length parameter comes AFTER the bar parameter,
and has type unsigned int, (not int), and you cannot seem to pack the whole thing
into a struct compatible with an ioctl like:
routine drm_version (
port: drm_t;
out bar: drm_version_t);
This part is hard coded in MiG, but could be changed easily.
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?
Can you provide more details on how this would be used? I assume clients would use ioctl but I am not too familiar with how glibc maps ioctl into RPCs.
My attempt at coding this is currently here [1] and [2].
Damien
[1] https://git.zammit.org/hurd-sv.git/commit/?h=drm-server
[2] https://git.zammit.org/hurd-sv.git/commit/?h=drm-server-ioctl
Regards
Flavio