[Bug 737316] Add support for sending file-descriptors over Unix domain sockets

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=737316
  GStreamer | gstreamer (core) | git

--- Comment #16 from Will Manley <gnome at williammanley.net> 2014-10-23 10:39:38 UTC ---
These patches have been uploaded mostly for posterity.  Between your comments
above, the pain I had to go through to implement this and a discussion I had
with wtay during the conference I agree a specialized sink and source could be
a better way to go, at least in the short term.

I still think that mapping Unix socket's ancillary data onto `GstBufferMeta` is
a sound idea because it expands the usefulness of the elements that already
know how to talk to sockets without reducing their usefulness in any other way.
 On the other hand I agree that making changes to GStreamer core itself to
support (what is now) just a single user is a little heavy-handed.  This may be
worth re-visiting when/if there are more users for it in GStreamer (e.g. more
fd-passing based wire protocols to implement).

For the time-being I'm happy for this bug to be closed.  I'll open a new one
for my revised implementation when it's ready.

Nonetheless I do think there has been some confusion about exactly what I was
proposing/have implemented here, and I'd like to address this for completeness:

(In reply to comment #5)
> fdsink/src is specialized for writing data into file descriptors, not socket.
> So as Sebastien says, this should be a new element. I'm not particularly fan of
> an hybrid between tcpsrc/sink and shmsrc/sink.

Note, there is no hybrid proposed here.  As before fdsink/fdsrc/multisocketsink
are used to talk to sockets, the only change is that they understand more of
the capabilities that sockets have, e.g. the fact that they support sending
ancillary data alongside the data payloads.

I think some of the confusion is caused by both sockets and memfds being
referred to by a file-descriptor from user-space, despite the fact that they
are very different beasts in kernel-space.

> I would personally prefer a
> design closer to shmsrc/sink, but with memfd allocator (hence memfd Memory).
> This same element, in reverse, should be able to zero copy memory that are
> backed by FDs and can be mmaped.

Indeed.  The intention was to cover the use cases that `shmsrc`/`shmsink`
cover, and expand on them.  `shmsink` and `shmsrc` work using a listening unix
socket to create connections between sender and receiver and then communicates
over that.  `shmsink` behaves like "fdpay ! unixserversink" and `shmsrc` like
"unixclientsrc ! fddepay".  OTOH the "PulseVideo" use-case uses `socketpair`
and DBus for creating connections so the pipelines look like "fdpay !
multisocketsink" and "fdsrc ! fddepay".  This is beyond the capabilities of
`shmsrc` and `shmsink` because `shmsrc` and `shmsink` implemented their own
socket code rather than reusing the code from other elements, whereas it's
natural in the fdpay/fddepay model as you can re-use the connection creation
mechanisms already implemented in other elements.

> By experience, the meta is really not the
> right place for this. In my opinion, we should make these new src/sink preserve
> the framing, so it becomes a inter process RTP friendly mechanism.

fdpay and fddepay preserve framing as currently implemented.

> The allocator interface proposed by Olivier is a really good starting point,
> since it's compatible with the existing code for GstDmabufAllocator, next to
> which we could add a GstMemfdAllocator (e.g. can be reused by a unix socket
> src/sink along with some kdbus adapter).

Agreed and this is what I've implemented.

> For the rest, a payloader does not need such a property. It should just keep
> doing what it's been doing so far.

Using `fdpay`/`fddepay` does not preclude also using rtpvrawpay/rtpvrawdepay. 
e.g. the pipeline:

    rtpvrawpay ! fdpay ! multisocketsink

is perfectly valid and shouldn't cause additional copying in theory.  In
practice I'd need to check how the rtp elements do their payloading to ensure
they aren't causing additional copies.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.