Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach: > It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote: >> Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach: >>> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote: >>>> Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach: >>>>> Regardless, of initrd issues I feel there is a need of a local IPC >>>>> that is more capable than UDS. Linus Torvalds is probably right that >>>>> dbus-daemon is everything but effictient. I disagree, however, that >>>>> it can be optimised and therefore solve *all* issues kdbus is trying >>>>> to address. dbus-deamon, by design, can't some things. It can't >>>>> transmitt large payloads without copying them. It can't be made >>>>> race-free. >>>> >>>> This is true. >>>> But as long dbus-deamon is not optimized as much as possible there is >>>> no reason to force push kdbus. >>>> As soon dbus-deamon exploits all kernel interfaces as much it can and >>>> it still needs work (may it performance or other stuff) we can think >>>> of new kernel features which can help dbus-deamon. >>> >>> I may not be well informed about kernel interfaces, but there are >>> some use cases no dbus-daemon optimisation can make work properly >>> because of rece-conditons introduced by the user-space based message >>> router. >>> >>> For example, a service can't aquire credentials of a client process that >>> actually sent a request (it can, but it can't trust them). The service >>> can't be protected by LSM on a bus that is driven by dbus-daemon. Yes, >>> dbus-daemon, can check client's and srevice's labels and enforce a >>> policy but it is going to be the daemon and not the LSM code in the >>> kernel. >> >> That's why I said we can think of new kernel features if they are >> needed. But they current sink or swim approach of kdbus folks is also >> not the solution. As I said, if dbus-daemon utilizes the kernel >> interface as much as possible we can think of new features. > > What kernel interfaces do you suggest to use to solve the issues > I mentioned in the second paragraph: race conditions, LSM support (for > example)?
The question is whether it makes sense to collect this kind of meta data. I really like Andy and Alan's idea improve AF_UNIX or revive AF_BUS. Thanks, //richard
signature.asc
Description: OpenPGP digital signature
