Re: [PATCH 01/13] kdbus: add documentation
From: Daniel Mack <hidden>
Date: 2015-02-03 10:09:54
Also in:
lkml
Hi Andy, On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
On Feb 2, 2015 1:34 AM, "Daniel Mack" [off-list ref] wrote:
quoted
That's right, but again - if an application wants to gather this kind of information about tasks it interacts with, it can do so today by looking at /proc or similar sources. Desktop machines do exactly that already, and the kernel code executed in such cases very much resembles that in metadata.c, and is certainly not cheaper. kdbus just makes such information more accessible when requested. Which information is collected is defined by bit-masks on both the sender and the receiver connection, and most applications will effectively only use a very limited set by default if they go through one of the more high-level libraries.I should rephrase a bit. Kdbus doesn't require use of send-time metadata. It does, however, strongly encourage it, and it sounds like
On the kernel level, kdbus just *offers* that, just like sockets offer SO_PASSCRED. On the userland level, kdbus helps applications get that information race-free, easier and faster than they would otherwise.
systemd and other major users will use send-time metadata. Once that happens, it's ABI (even if it's purely in userspace), and changing it is asking for security holes to pop up. So you'll be mostly stuck with it.
We know we can't break the ABI. At most, we could deprecate item types and introduce new ones, but we want to avoid that by all means of course. However, I fail to see how that is related to send time metadata, or even to kdbus in general, as all ABIs have to be kept stable.
Do you have some simple benchmark code you can share? I'd like to play with it a bit.
Sure, it's part of the self-test suite. Call it with "-t benchmark" to run the benchmark as isolated test with verbose output. The code for that lives in test-benchmark.c. Thanks, Daniel