On Sat, 1 Nov 2014 18:21:30 -0700 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > Here's some reasons why I feel it is better to have kdbus in the kernel > rather than trying to implement the same thing in a userspace daemon: No - these are reasons to have *something* in the kernel. I think it would be far more constructive to treat the current kdbus as a proof of concept/prototype or even a draft requirements specification. > as the only trustworthy compoenent in the game is the kernel which > adds metadata and ensures that all data passed as payload is either > copied or sealed, so that the receiver can parse the data without When the kernel adds metadata without being told to do so by one end of the link you create a new set of security and privacy leaks. Far better that the sender must choose what metadata is added and the receiver can decide to bin stuff that's not acceptable. The job of the kernel is really more like that of an auditor in a business transaction - to make sure that the data they agree to pass is truthful. (ie its the sender who must say "attach my user info", the receiver who must say "no info, no play" and the kernel who must provide the info so it can't be faked. > - semantics for apps with heavy data payloads (media apps, for instance) > with optinal priority message dequeuing, and global message ordering. Sounds like System 5 IPC ;-) > Regarding binder: binder and kdbus follow very different design > concepts. We know binder is broken but the Android guys are stuck in a special kind of hell with it for some years to come. We need to make sure kdbus isn't the same result. Alan -- 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
