Kay and Lennart, Thanks for taking the time to clarify everything. It's greatly appreciated.
Cheers, Justin On Tue, Feb 25, 2014 at 2:32 PM, Kay Sievers <k...@vrfy.org> wrote: > On Tue, Feb 25, 2014 at 9:18 PM, Justin Brown <justin.br...@fandingo.org> > wrote: >> On Tue, Feb 25, 2014 at 12:12 PM, Lennart Poettering >> <lenn...@poettering.net> wrote: >>> On Tue, 25.02.14 10:41, Justin Brown (justin.br...@fandingo.org) wrote: >>> >>> And broadcast signals should never be large datagrams, but >>> only very short. >> >> Could you elaborate on this point? One of the major points of emphasis >> with kdbus seems to be performance. Why is that restricted to method >> calls? I understand that there would be implementation complexities in >> multiplexing memfds to all of the signal subscribers, but it seems >> like a desirable feature. A single source application that sends >> relatively large amounts of data (a few KB up to possibly several GB) >> to several third-party sinks seems like a natural use of memfds. > > Broadcasting complex kernel objects like file descriptors inside the > kernel to many connections at the same time is outside of the focus of > kdbus. Things get really fragile very fast if we would allow such > things. > >> As far as I can tell, the only way to accomplish this with kdbus would >> be for the source application to have a subscribe() method, so it >> could send methods to each sink. I apologize for asking such a >> simplistic question (I don't have my kdbus VM up and running yet.), >> but if I were to take this route, can the same memfd be used in >> multiple methods or would a new one need to be created for each >> subscriber? > > You can send any kind of file descriptor many times, therefore also > memfds can be send many times. > > Memfds are special that they can be used to carry *payload* of a dbus > message, not only be a naked fd. These memfds need to be sealed to get > accepted as payload, but they can be used multiple times too. > > Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel