[systemd-devel] [k]dbus: api, match replace and test extending

[Rui Miguel Silva]

On Mon, Nov 17, 2014 at 11:00:52AM +0100, Lennart Poettering wrote:
> On Mon, 17.11.14 00:23, Rui Miguel Silva (rmfrfs at gmail.com) wrote:
> 
> > Hi,
> > 
> > I have some questions regarding kdbus/dbus, maybe some could assist:
> > 
> > 1\ api: when it is exported explicity bloom as filter implementation dont
> > you think that:
> >      - exporting through api an internal implementation, maybe it is not
> >        a good idea
> 
> What do you mean by that? 
> 
> Note that the parameters of the bloom filter are communicated via
> HELLO ioctl when you connect. This allows us to alter the parameters
> later on should that be necessary.
> 
> Also, there's a feature negotiation scheme as well as "filter
> versioning" available which allows us to change the filtering scheme
> evenutally should this be necessary, without having to update all
> clients at once.
> 
> We hence carefully made sure that we have a variety of "soft" ways how
> we can still alter the filtering scheme later on, after the first
> release.
> 
> That said, we also carefully selected the initial parameters we will
> use by default. For example, the hash function we use is SipHash,
> which is actually overkill for what we need (it's cryptographic which
> is a property we don't need), and we defined a set of seeds that are
> substantially more than we will need with the initial bloom filter
> parameters.
Yes, that is understood and it is a wise decision.
> 
> >      - technical debt, if in the future the filter mechanism is change by
> >        other than bloom.
> > so bloom maybe just be replaced with only generic filter could make more
> > sense?
> 
> What do you mean by "only generic filter"?
> 
Maybe I did not explain myself well, what I mean is:
Imagine that ahead we find that instead of bloom filtering mechanism, for
example, cuckoo filters are more eficient. The api have the filter
structs called struct kdbus_bloom_filter, my suggestion was to just change
that to struct kdbus_filter (and no attach to filter specific
implementation). Since they are very generic (generation and a data field)
and for the kdbus it is just a check between a mask and a filter.
> > 2\ match_replace: it is not clear to me from the docs what should be the
> > behaviour when using the KDBUS_MATCH_REPLACE flag and the match with the
> > given cookie does not exist. In the implementation it is obvious that it
> > will add as a new match. but it is a feature or bug?
> 
> This is a feature. It's about atomic replace really.
thanks.
> 
> > 3\ testing: it is of any interess to provide more test code and cases at
> > kdbus level? or do not want to increase the testing scenario?
> 
> We are always interested in more test cases. In both sd-bus on the
> systemd side, as well as in the kdbus/kernel repository!
will try to contribute.

Cheers,
    Rui
> 
> Hope this is useful!
> 
> Lennart
> 
> -- 
> Lennart Poettering, Red Hat