On Mon, Nov 17, 2014 at 11:00:52AM +0100, Lennart Poettering wrote: > On Mon, 17.11.14 00:23, Rui Miguel Silva (rmf...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel