Reworking our support for platform specific functions

[Alexandros Frantzis]

On Tue, Oct 14, 2014 at 12:00:59PM +0100, Alan Griffiths wrote:
> On 13/10/14 12:37, Alexandros Frantzis wrote:
<snip>
> >
> > Client API: mir_connection_platform_operation(type, DataAndFds request, ...);
> > Client    : MirConnection::platform_operation(type, ...)
> > Protobuf  : rpc platform_operation(type, DataAndFds) returns (DataAndFds)
> > Server    : SessionMediator::platform_operation()
> > Platform  : DataAndFds PlatformIpcOperations::platform_operation(type, DataAndFds)
> >
> > Each platform should expose a header with its operation types and
> > expected parameters types. For mesa it could be something like:
> >
> > enum MesaPlatformOperationType { drm_auth_magic, drm_get_auth_fd };
> > struct DRMAuthMagicRequest { int magic; }
> > struct DRMAuthMagicReply { int status; }
> > ...
> >
> > And a request would be:
> >
> > DRMAuthMagicRequest request = { magic };
> >
> > void platform_operation_callback(
> >     MirConnection* connection, DataAndFds const* reply, void* context)
> > {
> >     struct DRMAuthMagicReply const* magic_reply = reply->data;
> >     ...
> > }
> >
> > mir_connection_platform_operation(
> >     drm_auth_magic, request, platform_operation_callback);
<snip>
> > Thoughts?
> 
> I like the general approach, but have concerns about a bit of the detail.

A caveat: the original email was meant mainly to illustrate the overall
approach, I didn't focus on the details much (e.g. names and types are
all tentative).

> 1. Is there any point to having separating "type" from "data" and "fds"?
> Or should the various data structures combine all three.

We could avoid exposing any structure, apart from data vs fds (see
below).

> 2. In the client API would be good to use an opaque "PlatformMessage"
> type, rather than a DataAndFds struct.

We need to be able to separate the fds from the rest of the data, so
that our RPC layer can send the fds properly. That's what the
(tentative) name was trying to convey.

> E.g.
> 
>    DRMAuthMagicReply const* magic_reply = (DRMAuthMagicReply const*)mir_platform_get_data(reply);
> 
> 3. With a C API we have to be explicit about ownership. E.g. does the client have to release 
> magic_reply or does it become invalid after the call?

We could go either way, weighing the cost of copying data (and dup()-ing
fds) vs the potential for memory/fd leaks. Let's be consistent with how
we handle other similar cases in the client API (do we have other such
cases?).

> 4. Do we need to address byte encoding, sizes and alignment of platform data?

I would say not in Mir. If a message has special needs, the sender
should take care to serialize/deserialize it properly.

Thanks,
Alexandros