On 31/05/16 10:46, Alex Bennée wrote: > Sergey Fedorov <serge.f...@gmail.com> writes: > >> On 25/05/16 04:13, Emilio G. Cota wrote: >>> diff --git a/include/qemu/qht.h b/include/qemu/qht.h >>> new file mode 100644 >>> index 0000000..aec60aa >>> --- /dev/null >>> +++ b/include/qemu/qht.h >>> @@ -0,0 +1,183 @@ >> (snip) >>> +/** >>> + * qht_init - Initialize a QHT >>> + * @ht: QHT to be initialized >>> + * @n_elems: number of entries the hash table should be optimized for. >>> + * @mode: bitmask with OR'ed QHT_MODE_* >>> + */ >>> +void qht_init(struct qht *ht, size_t n_elems, unsigned int mode); >> First of all, thank you for spending your time on the documentation of >> the API! >> >> I was just wondering if it could be worthwhile to pass a hash function >> when initializing a QHT. Then we could have variants of qht_insert(), >> qht_remove() and qht_lookup() which does not require a computed hash >> value but call the function by themselves. This could make sense since a >> hash value passed the the functions should always be exactly the same >> for the same object. > Wouldn't this be for an expansion of the API when we actually have > something that would use it that way? >
Yes, I think in "tb hash: track translated blocks with qht" we could just pass tb_hash_func() to qht_init(). Kind regards, Sergey
