On Mon, 17.11.14 12:31, Rui Miguel Silva (rmf...@gmail.com) wrote: Heya,
> > > - 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. I had a closer look at cuckoo filters now. The lookup logic is quite different from bloom filters and involves iterating through "entries" of a bucket. Now, I am not convinced that Cuckoo filters are really something we want to do in kdbus, but should we determine one day that they in fact are, then the kernel side matching of filter against mask needs to look very different anyway, with different data structures. And in that case we really should define new items for that, that should not overload the existing kdbus_bloom_filter structures but be seperate, new structs. Hope this makes sense, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
