Hello,
I'm currently thinking up how channel's control interface (a la ioctl)
will look like and I need some input.
I have a fairly good idea of how the backend will look like in
libchannel itself (more on this once the following is resolved.) But
getting dynamically extensible IPC for it is a bit trickier, as we
want to be able to dynamically load in channel classes into a
channelio translater (at start-up) that can handle RPCs that are
unknown by libchannel and channelio.
I can think of two models.
(1) Have a ioctl-like remote procedure which take a control code and
have the control specific parameteres marshaled into a buffer.
(2) Have one remote procedure per control.
(2) would be the most hurdish one, with MIG doing most of the work.
However MIG server code only handles routines available during
generation. Either MIG must be circumvented or hacked to use a hook
that handles unknown messages (might be generally useful.) Is this
feasible to implement or is there another way to achieve this?
(1) one is ugly but straight forward to implement. However assigning
unique control codes and (un)marshaling parameters into a struct is a
pain, which ofcourse could be fixed by writing interface generator,
i.e. like (2) only much more complicated.
What do you guys think?
Cheers,
Fredrik
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
