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

2024-11-05 Thread Sergey Bugaev
On Tue, Nov 5, 2024 at 10:16 AM Yuqian Yang 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 v

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

2024-11-05 Thread Samuel Thibault
Hello, Note that you are not stuck with ioctl's parsing. You can use _HURD_HANDLE_IOCTL and _HURD_HANDLE_IOCTLS to define client-side interpretation of of the ioctl parameter, to be able to cast that into an RPC just like you prefer instead of the IOT things. Samuel

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

2024-11-04 Thread Yuqian Yang
It sounds like we need to implement a wrapping-paper thin layer in libdrm that unpacks drmIoctl() and fans out all the combinations of proper RPCs; it will be ugly but doable. (I was hoping we could just pass in a casted struct as that is what an ioctl is for). This is more work, but probably s

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

2024-11-04 Thread Damien Zammit via Bug reports for the GNU Hurd
Hi, On 11/5/24 6:16 PM, Yuqian Yang wrote: > 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

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

2024-11-04 Thread Yuqian Yang
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

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

2024-11-04 Thread Sergey Bugaev
On Mon, Nov 4, 2024 at 10:44 AM Damien Zammit wrote: > 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

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

2024-11-04 Thread Flávio Cruz
Hello Damien On Mon, Nov 4, 2024 at 2:44 AM Damien Zammit via Bug reports for the GNU Hurd 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 u

[RFC: drm server] limitations of MiG for ioctls

2024-11-03 Thread Damien Zammit via Bug reports for the GNU Hurd
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 s