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;
};
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);
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?
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
