Hello, Sasha. On Fri, Aug 24, 2012 at 09:47:19PM +0200, Sasha Levin wrote: > > I think this is problematic. It looks exactly like other existing > > DEFINE macros yet what its semantics is different. I don't think > > that's a good idea. > > I can switch that to be DECLARE_HASHTABLE() if the issue is semantics. If this implementation is about the common trivial case, why not just have the usual DECLARE/DEFINE_HASHTABLE() combination? > > So, I think it would be best to keep this one as straight-forward and > > trivial as possible. Helper macros to help its users are fine but > > let's please not go for full encapsulation. > > What if we cut off the dynamic allocated (but not resizable) hashtable out for > the moment, and focus on the most common statically allocated hashtable case? > > The benefits would be: > > - Getting rid of all the _size() macros, which will make the amount of helpers > here reasonable. > - Dynamically allocated hashtable can be easily added as a separate > implementation using the same API. We already have some of those in the kernel... It seems we have enough of this static usage and solving the static case first shouldn't hinder the dynamic (!resize) case later, so, yeah, sounds good to me. > - When that's ready, I feel it's a shame to lose full encapsulation just due to > hash_hashed(). I don't know. If we stick to the static (or even !resize dymaic) straight-forward hash - and we need something like that - I don't see what the full encapsulation buys us other than a lot of trivial wrappers. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
