On Jan 29, 2015 6:42 AM, "Daniel Mack" <daniel@xxxxxxxxxx> wrote: > > On 01/29/2015 12:25 PM, Andy Lutomirski wrote: > > On Jan 29, 2015 3:53 AM, "Daniel Mack" <daniel@xxxxxxxxxx> wrote: > > >> Also note that if a receiving peer opts in for a certain piece of > >> metadata, it should do that that for a good reason, because it needs > >> that data to process a request. Letting kdbus do the work of providing > >> such information is still a lot faster than having the receiving peer > >> gather it itself, as that would involve more syscalls and more context > >> switches (let alone the fact that doing so is inherently racy, as > >> explained in earlier threads). > > > Given that I see almost no advantage to send-time metadata, and I see > > three disadvantages (slower, inconsistent with the basic POSIX model, > > and inconsistent with existing user-space dbus), I still don't see why > > you designed it this way. > > Because effective information about tasks may change over time, and > D-Bus is a connection-less protocol that has no notion of peer-to-peer > connections. > > As we explained before, currently, D-Bus peers do collect the same > information already if they need to have them, but they have to do deal > with the inherit races in such cases. kdbus is closing the gap by > optionally providing the same information along with each message, if > requested. In all these discussions, no one ever gave a decent example use case. If a process drops some privilege, it must close all fds it has that captured its old privilege. This has nothing to do with kdbus. With kdbus, you still need to close and reopen your kdbus fd, unless you've disabled that bit of metadata, so using send-time metadata hasn't bought you benefit that I can see. I agree that the design seems to have improved to a state of being at least decent, but that doesn't mean that using send-time metadata is a good idea for systemd or for anything else. > > > There's an added disadvantage of the current design: if a kdbus user > > is communicating with a traditional d-bus user using the proxy, then > > IIUC the credentials at the time of connection get used. > > That's not quite true any more. After our discussion in v2, we agreed on > dropping this detail. If you're using the proxy, no metadata is attached > to messages any more. Userspace has to gather this information in the > traditional, racy way in such cases. You are right - metadata about the > proxy task is of no interest here, and hence dropping the information > altogether is the most consistent thing we can do. > > But again - that metadata thing just an optional feature. People > developing with the bare kernel-level API are free to ignore all that > and just just kdbus as low-level protocol for reliable multicast. Note > that in such cases, you would still be able to retrieve the connect-time > metadata if that's needed. > It's an optional feature that will get used, non-optionally, thousands of times on each boot, apparently. Keep in mind that it's also a scalability problem because it takes locks. If it ever gets used thousands of times per CPU on a big thousand-core machine, it's going to suck, and you'll have backed yourself into a corner. --Andy -- 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
