It was <2015-04-30 czw 14:45>, when Richard Weinberger wrote:
> Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
>> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
>>> 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. 
>> [...]
>>>>>> 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.
>> 
>> Race conditions have nothing to do with metadata. Neither has LSM
>> support.
>
> Sorry, I thought you mean the races while collecting metadata in userspace...

My bad, some reace conditions *are* associated with collecting metadata
but ont all. It is impossible (correct me if I am wrong) to implement
reliable die-on-idle with dbus-daemon.

>> AF_UNIX with multicast support wouldn't be AF_UNIX anymore.
>> 
>> AF_BUS? I haven't followed the discussion back then. Why do you think it
>> is better than kdbus?
>
> Please see https://lwn.net/Articles/641278/

Thanks. If I understand correctly, the author suggests using EBPF on a
receiveing socket side for receiving multicast messages. This is nice if
you care about introducing (or not) (too?) much of new code. However,
AFAICT it may be more computationally complex than Bloom filters because
you need to run EBPF on every receiving socket instead of getting a list
of a few of them to copy data to. Of course for small number of
receivers the "constant" cost of running the Bloom filter may be higher.

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics