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. > 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. Thanks, Daniel -- 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
