On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack <daniel@xxxxxxxxxx> wrote: > Hi Andy, > > On 02/02/2015 09:12 PM, Andy Lutomirski wrote: >> On Feb 2, 2015 1:34 AM, "Daniel Mack" <daniel@xxxxxxxxxx> wrote: > >>> 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. I should have said it differently. ABI is the wrong term -- it's more of a protocol issue. It looks like, with the current code, the kernel will provide (optional) send-time metadata, and the sd-bus library will use it. The result will be that the communication protocol between clients and udev, systemd, systemd-logind, g-s-d, etc, will likely involve send-time metadata. This may end up being a bottleneck. Once this happens, changing the protocol will be very hard without introducing security bugs. If people start switching to connection-time metadata to gain performance, then they'll break both the communication protocol and the expectations of client code. (In fact, it'll break twice, sort of, since I think that the current protocols are connect-time.) To me, this seems like a down-side of using send-time metadata, albeit possibly not a huge downside at least in the near term. I don't see a corresponding benefit, though. > >> 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. > I'll try to play with this soon. Thanks. --Andy > > Thanks, > Daniel > > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
