From: Tejun Heo <tj@kernel.org>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
paul.gortmaker@windriver.com, davem@davemloft.net,
rostedt@goodmis.org, mingo@elte.hu, ebiederm@xmission.com,
aarcange@redhat.com, ericvh@gmail.com, netdev@vger.kernel.org
Subject: Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
Date: Fri, 3 Aug 2012 14:30:17 -0700 [thread overview]
Message-ID: <20120803213017.GK15477@google.com> (raw)
In-Reply-To: <501C407D.9080900@gmail.com>
Hello,
On Fri, Aug 03, 2012 at 11:19:57PM +0200, Sasha Levin wrote:
> > Is this supposed to be embedded in struct definition? If so, the name
> > is rather misleading as DEFINE_* is supposed to define and initialize
> > stand-alone constructs. Also, for struct members, simply putting hash
> > entries after struct hash_table should work.
>
> It would work, but I didn't want to just put them in the union since
> I feel it's safer to keep them in a separate struct so they won't be
> used by mistake,
Just use ugly enough pre/postfixes. If the user still accesses that,
it's the user's fault.
> >> +static void hash_init(struct hash_table *ht, size_t bits)
> >> +{
> >> + size_t i;
> >
> > I would prefer int here but no biggie.
>
> Just wondering, is there a particular reason behind it?
It isn't a size and using unsigned when signed suffices seems to cause
more headache than helps anything usually due to lack of values to use
for exceptional conditions (usually -errno or -1).
> > As opposed to using hash_for_each_possible(), how much difference does
> > this make? Is it really worthwhile?
>
> Most of the places I've switched to using this hashtable so far (4
> out of 6) are using hash_get(). I think that the code looks cleaner
> when you an just provide a comparison function instead of
> implementing the iteration itself.
>
> I think hash_for_for_each_possible() is useful if the comparison
> condition is more complex than a simple comparison of one of the
> object members with the key - there's no need to force it on all the
> users.
I don't know. What's the difference? In terms of LOC, it might even
not save any thanks to the extra function definition, right? I don't
think it's saving enough complexity to justify a separate rather
unusual interface.
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
paul.gortmaker@windriver.com, davem@davemloft.net,
rostedt@goodmis.org, mingo@elte.hu, ebiederm@xmission.com,
aarcange@redhat.com, ericvh@gmail.com, netdev@vger.kernel.org
Subject: Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
Date: Fri, 3 Aug 2012 14:30:17 -0700 [thread overview]
Message-ID: <20120803213017.GK15477@google.com> (raw)
In-Reply-To: <501C407D.9080900@gmail.com>
Hello,
On Fri, Aug 03, 2012 at 11:19:57PM +0200, Sasha Levin wrote:
> > Is this supposed to be embedded in struct definition? If so, the name
> > is rather misleading as DEFINE_* is supposed to define and initialize
> > stand-alone constructs. Also, for struct members, simply putting hash
> > entries after struct hash_table should work.
>
> It would work, but I didn't want to just put them in the union since
> I feel it's safer to keep them in a separate struct so they won't be
> used by mistake,
Just use ugly enough pre/postfixes. If the user still accesses that,
it's the user's fault.
> >> +static void hash_init(struct hash_table *ht, size_t bits)
> >> +{
> >> + size_t i;
> >
> > I would prefer int here but no biggie.
>
> Just wondering, is there a particular reason behind it?
It isn't a size and using unsigned when signed suffices seems to cause
more headache than helps anything usually due to lack of values to use
for exceptional conditions (usually -errno or -1).
> > As opposed to using hash_for_each_possible(), how much difference does
> > this make? Is it really worthwhile?
>
> Most of the places I've switched to using this hashtable so far (4
> out of 6) are using hash_get(). I think that the code looks cleaner
> when you an just provide a comparison function instead of
> implementing the iteration itself.
>
> I think hash_for_for_each_possible() is useful if the comparison
> condition is more complex than a simple comparison of one of the
> object members with the key - there's no need to force it on all the
> users.
I don't know. What's the difference? In terms of LOC, it might even
not save any thanks to the extra function definition, right? I don't
think it's saving enough complexity to justify a separate rather
unusual interface.
Thanks.
--
tejun
next prev parent reply other threads:[~2012-08-03 21:30 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-03 14:23 [RFC v2 0/7] generic hashtable implementation Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-03 14:23 ` [RFC v2 1/7] hashtable: introduce a small and naive hashtable Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-03 17:15 ` Tejun Heo
2012-08-03 17:15 ` Tejun Heo
2012-08-03 17:16 ` Tejun Heo
2012-08-03 17:16 ` Tejun Heo
2012-08-03 21:19 ` Sasha Levin
2012-08-03 21:19 ` Sasha Levin
2012-08-03 21:30 ` Tejun Heo [this message]
2012-08-03 21:30 ` Tejun Heo
2012-08-03 21:36 ` Sasha Levin
2012-08-03 21:36 ` Sasha Levin
2012-08-03 21:44 ` Tejun Heo
2012-08-03 21:44 ` Tejun Heo
2012-08-03 21:41 ` Sasha Levin
2012-08-03 21:41 ` Sasha Levin
2012-08-03 21:48 ` Tejun Heo
2012-08-03 21:48 ` Tejun Heo
2012-08-03 22:20 ` Sasha Levin
2012-08-03 22:20 ` Sasha Levin
2012-08-03 22:23 ` Tejun Heo
2012-08-03 22:23 ` Tejun Heo
2012-08-03 22:26 ` Sasha Levin
2012-08-03 22:26 ` Sasha Levin
2012-08-03 22:29 ` Linus Torvalds
2012-08-03 22:29 ` Linus Torvalds
2012-08-03 22:36 ` Tejun Heo
2012-08-03 22:36 ` Tejun Heo
2012-08-03 23:47 ` Linus Torvalds
2012-08-03 23:47 ` Linus Torvalds
2012-08-04 0:03 ` Sasha Levin
2012-08-04 0:03 ` Sasha Levin
2012-08-04 0:05 ` Linus Torvalds
2012-08-04 0:05 ` Linus Torvalds
2012-08-04 0:33 ` Sasha Levin
2012-08-04 0:33 ` Sasha Levin
2012-08-04 0:05 ` Tejun Heo
2012-08-04 0:05 ` Tejun Heo
2012-08-03 17:39 ` Eric Dumazet
2012-08-03 17:39 ` Eric Dumazet
2012-08-03 14:23 ` [RFC v2 2/7] user_ns: use new hashtable implementation Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-05 0:58 ` Eric W. Biederman
2012-08-05 0:58 ` Eric W. Biederman
2012-08-03 14:23 ` [RFC v2 3/7] mm,ksm: " Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-03 14:23 ` [RFC v2 4/7] workqueue: " Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-03 14:23 ` [RFC v2 5/7] mm/huge_memory: " Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-03 14:23 ` [RFC v2 6/7] tracepoint: " Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-05 0:36 ` Steven Rostedt
2012-08-05 0:36 ` Steven Rostedt
2012-08-05 16:31 ` Mathieu Desnoyers
2012-08-05 16:31 ` Mathieu Desnoyers
2012-08-05 17:03 ` Sasha Levin
2012-08-05 17:03 ` Sasha Levin
2012-08-05 17:12 ` Mathieu Desnoyers
2012-08-05 17:12 ` Mathieu Desnoyers
2012-08-03 14:23 ` [RFC v2 7/7] net,9p: " Sasha Levin
2012-08-03 14:23 ` Sasha Levin
2012-08-03 18:00 ` Eric Dumazet
2012-08-03 18:00 ` Eric Dumazet
2012-08-03 21:14 ` Sasha Levin
2012-08-03 21:14 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120803213017.GK15477@google.com \
--to=tj@kernel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=ericvh@gmail.com \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.