[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 #17 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> 2014-10-23 15:08:13 UTC ---
(In reply to comment #16)
> (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.

fdsrc/fdsink are not specialized for socket, normal file descriptors (files,
pipe, etc.) are expected to work.

> 
> > 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.

For the reference, the shmsrc/shmsink designed was tailored to very small peace
of data and framing (RTP). So shmsrc/shmsink implement a protocol that allow
multiplexing a larger SHM area, reducing the overhead. The problem I've hit so
far, is that it's protocol isn't easily extensible, so adding abitlity to pass
sub region of the main SHM area along with passing other FDs that would pass by
would break the protocol backward compatibility.

Outside that I'm not convince of the overload of fdsrc and fdsink I'd like to
thanks you for taking the time to experiment this and sharing your experience
at the GStreamer Conference. Until your talk, it wasn't that clear to me what
this design was about. My interest into this is mainly DMABUF fd passing,
though looking at what is going on the kernel side, I'm starting to foresee
something that would allow combination of memfd and KDBus to fulfill this task.

-- 
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.