On Thu, 2012-09-06 at 18:21 +0200, Sasha Levin wrote:
> On 09/06/2012 06:00 PM, Steven Rostedt wrote:
> >> > I think that that code doesn't make sense. The users of hlist_for_each_*
> >> > aren't
> >> > supposed to be changing the loop cursor.
> > I totally agree. Modifying the 'node' pointer is
* Sasha Levin (levinsasha...@gmail.com) wrote:
> On 09/06/2012 06:50 PM, Mathieu Desnoyers wrote:
> > * Sasha Levin (levinsasha...@gmail.com) wrote:
> >> On 09/06/2012 06:00 PM, Steven Rostedt wrote:
> > I think that that code doesn't make sense. The users of
> > hlist_for_each_* aren't
>
On 09/06/2012 06:50 PM, Mathieu Desnoyers wrote:
> * Sasha Levin (levinsasha...@gmail.com) wrote:
>> On 09/06/2012 06:00 PM, Steven Rostedt wrote:
> I think that that code doesn't make sense. The users of hlist_for_each_*
> aren't
> supposed to be changing the loop cursor.
>>> I
* Sasha Levin (levinsasha...@gmail.com) wrote:
> On 09/06/2012 06:00 PM, Steven Rostedt wrote:
> >> > I think that that code doesn't make sense. The users of hlist_for_each_*
> >> > aren't
> >> > supposed to be changing the loop cursor.
> > I totally agree. Modifying the 'node' pointer is just
On 09/06/2012 06:00 PM, Steven Rostedt wrote:
>> > I think that that code doesn't make sense. The users of hlist_for_each_*
>> > aren't
>> > supposed to be changing the loop cursor.
> I totally agree. Modifying the 'node' pointer is just asking for issues.
> Yes that is error prone, but not due
On Thu, 2012-09-06 at 17:49 +0200, Sasha Levin wrote:
>
> > Looks reasonable. However, it would break (or rather, not break) on
> > code like this:
> >
> > hash_for_each_entry(...) {
> > if (...) {
> > foo(node);
> > node = NULL;
ug, I
On 09/06/2012 04:55 PM, Josh Triplett wrote:
> On Thu, Sep 06, 2012 at 03:53:58PM +0200, Sasha Levin wrote:
>> On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
#define do_for_each_ftrace_rec(pg, rec)
\
> for (pg = ftrace_pages_start,
On Thu, 2012-09-06 at 07:55 -0700, Josh Triplett wrote:
> > My solution to making 'break' work in the iterator is:
> >
> > for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node == NULL; bkt++)
> > hlist_for_each_entry(obj, node, [bkt], member)
> >
>
> Looks reasonable.
On Thu, Sep 06, 2012 at 03:53:58PM +0200, Sasha Levin wrote:
> On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
> >> #define do_for_each_ftrace_rec(pg, rec)
> >> \
> >> > for (pg = ftrace_pages_start, rec = >records[pg->index];
> >> >
> My solution to making 'break' work in the iterator is:
>
> for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node ==
NULL; bkt++)
> hlist_for_each_entry(obj, node, [bkt], member)
I'd take a look at the generated code.
Might come out a bit better if the condition is
* Sasha Levin (levinsasha...@gmail.com) wrote:
> On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
> >> #define do_for_each_ftrace_rec(pg, rec)
> >> \
> >> > for (pg = ftrace_pages_start, rec = >records[pg->index];
> >> > \
> >> >
On 09/06/2012 02:53 PM, Sasha Levin wrote:
> So I think that for the hash iterator it might actually be simpler.
>
> My solution to making 'break' work in the iterator is:
>
> for (bkt = 0, node = NULL; bkt < HASH_SIZE(name) && node == NULL; bkt++)
>
On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
>> #define do_for_each_ftrace_rec(pg, rec)
>> \
>> > for (pg = ftrace_pages_start, rec = >records[pg->index];
>> > \
>> > pg && rec == >records[pg->index];
On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
#define do_for_each_ftrace_rec(pg, rec)
\
for (pg = ftrace_pages_start, rec = pg-records[pg-index];
\
pg rec == pg-records[pg-index];
On 09/06/2012 02:53 PM, Sasha Levin wrote:
So I think that for the hash iterator it might actually be simpler.
My solution to making 'break' work in the iterator is:
for (bkt = 0, node = NULL; bkt HASH_SIZE(name) node == NULL; bkt++)
hlist_for_each_entry(obj, node,
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
#define do_for_each_ftrace_rec(pg, rec)
\
for (pg = ftrace_pages_start, rec = pg-records[pg-index];
\
pg rec ==
My solution to making 'break' work in the iterator is:
for (bkt = 0, node = NULL; bkt HASH_SIZE(name) node ==
NULL; bkt++)
hlist_for_each_entry(obj, node, name[bkt], member)
I'd take a look at the generated code.
Might come out a bit better if the condition is changed
On Thu, Sep 06, 2012 at 03:53:58PM +0200, Sasha Levin wrote:
On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
#define do_for_each_ftrace_rec(pg, rec)
\
for (pg = ftrace_pages_start, rec = pg-records[pg-index];
\
On Thu, 2012-09-06 at 07:55 -0700, Josh Triplett wrote:
My solution to making 'break' work in the iterator is:
for (bkt = 0, node = NULL; bkt HASH_SIZE(name) node == NULL; bkt++)
hlist_for_each_entry(obj, node, name[bkt], member)
Looks reasonable. However, it
On 09/06/2012 04:55 PM, Josh Triplett wrote:
On Thu, Sep 06, 2012 at 03:53:58PM +0200, Sasha Levin wrote:
On 09/04/2012 07:01 PM, Mathieu Desnoyers wrote:
#define do_for_each_ftrace_rec(pg, rec)
\
for (pg = ftrace_pages_start, rec =
On Thu, 2012-09-06 at 17:49 +0200, Sasha Levin wrote:
Looks reasonable. However, it would break (or rather, not break) on
code like this:
hash_for_each_entry(...) {
if (...) {
foo(node);
node = NULL;
ug, I didn't even
On 09/06/2012 06:00 PM, Steven Rostedt wrote:
I think that that code doesn't make sense. The users of hlist_for_each_*
aren't
supposed to be changing the loop cursor.
I totally agree. Modifying the 'node' pointer is just asking for issues.
Yes that is error prone, but not due to the
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 09/06/2012 06:00 PM, Steven Rostedt wrote:
I think that that code doesn't make sense. The users of hlist_for_each_*
aren't
supposed to be changing the loop cursor.
I totally agree. Modifying the 'node' pointer is just asking for
On 09/06/2012 06:50 PM, Mathieu Desnoyers wrote:
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 09/06/2012 06:00 PM, Steven Rostedt wrote:
I think that that code doesn't make sense. The users of hlist_for_each_*
aren't
supposed to be changing the loop cursor.
I totally agree. Modifying
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 09/06/2012 06:50 PM, Mathieu Desnoyers wrote:
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 09/06/2012 06:00 PM, Steven Rostedt wrote:
I think that that code doesn't make sense. The users of
hlist_for_each_* aren't
supposed to be
On Thu, 2012-09-06 at 18:21 +0200, Sasha Levin wrote:
On 09/06/2012 06:00 PM, Steven Rostedt wrote:
I think that that code doesn't make sense. The users of hlist_for_each_*
aren't
supposed to be changing the loop cursor.
I totally agree. Modifying the 'node' pointer is just asking for
On Tue, 2012-09-04 at 23:58 +0100, Pedro Alves wrote:
> Not true. The comma operator introduces a sequence point. It's the comma
> that separates function parameters that doesn't guarantee ordering.
Bah! C language is almost as confusing as English.
-- Steve
--
To unsubscribe from this
On 09/04/2012 11:41 PM, Steven Rostedt wrote:
> Ah, I missed the condition with the rec == >records[pg->index]. But
> if ftrace_pages_start is NULL, the rec = >records[pg->index] will
> fault.
Right.
>
> You could do something like rec = pg ? >records[pg->index] : NULL,
Right.
> but IIRC, the
On Tue, 2012-09-04 at 22:51 +0100, Pedro Alves wrote:
> On 09/04/2012 09:59 PM, Steven Rostedt wrote:
> > On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
> >> On 09/04/2012 06:17 PM, Steven Rostedt wrote:
> >>> On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
> >>>
> BTW, you can
On 09/04/2012 09:59 PM, Steven Rostedt wrote:
> On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
>> On 09/04/2012 06:17 PM, Steven Rostedt wrote:
>>> On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
>>>
BTW, you can also go a step further and remove the need to close with
On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
> On 09/04/2012 06:17 PM, Steven Rostedt wrote:
> > On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
> >
> >> BTW, you can also go a step further and remove the need to close with
> >> double }},
> >> with something like:
> >>
> >>
On 09/04/2012 06:17 PM, Steven Rostedt wrote:
> On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
>
>> BTW, you can also go a step further and remove the need to close with double
>> }},
>> with something like:
>>
>> #define do_for_each_ftrace_rec(pg, rec)
On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
> BTW, you can also go a step further and remove the need to close with double
> }},
> with something like:
>
> #define do_for_each_ftrace_rec(pg, rec)
>\
> for (pg = ftrace_pages_start, rec
* Pedro Alves (pal...@redhat.com) wrote:
> On 09/04/2012 05:30 PM, Pedro Alves wrote:
> > On 09/04/2012 04:35 PM, Steven Rostedt wrote:
> >> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
> >>
> >>> Looking again at:
> >>>
> >>> +#define hash_for_each_size(name, bits, bkt, node, obj,
On 09/04/2012 05:30 PM, Pedro Alves wrote:
> On 09/04/2012 04:35 PM, Steven Rostedt wrote:
>> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>>
>>> Looking again at:
>>>
>>> +#define hash_for_each_size(name, bits, bkt, node, obj, member)
>>> \
>>> + for (bkt =
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>
> > Looking again at:
> >
> > +#define hash_for_each_size(name, bits, bkt, node, obj, member)
> > \
> > + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)
On 09/04/2012 04:35 PM, Steven Rostedt wrote:
> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>
>> Looking again at:
>>
>> +#define hash_for_each_size(name, bits, bkt, node, obj, member)
>>\
>> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)
On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
> Looking again at:
>
> +#define hash_for_each_size(name, bits, bkt, node, obj, member)
> \
> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)
> \
> +
On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
Looking again at:
+#define hash_for_each_size(name, bits, bkt, node, obj, member)
\
+ for (bkt = 0; bkt HASH_SIZE(bits); bkt++)
\
+ hlist_for_each_entry(obj,
On 09/04/2012 04:35 PM, Steven Rostedt wrote:
On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
Looking again at:
+#define hash_for_each_size(name, bits, bkt, node, obj, member)
\
+ for (bkt = 0; bkt HASH_SIZE(bits); bkt++)
\
* Steven Rostedt (rost...@goodmis.org) wrote:
On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
Looking again at:
+#define hash_for_each_size(name, bits, bkt, node, obj, member)
\
+ for (bkt = 0; bkt HASH_SIZE(bits); bkt++)
On 09/04/2012 05:30 PM, Pedro Alves wrote:
On 09/04/2012 04:35 PM, Steven Rostedt wrote:
On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
Looking again at:
+#define hash_for_each_size(name, bits, bkt, node, obj, member)
\
+ for (bkt = 0; bkt
* Pedro Alves (pal...@redhat.com) wrote:
On 09/04/2012 05:30 PM, Pedro Alves wrote:
On 09/04/2012 04:35 PM, Steven Rostedt wrote:
On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
Looking again at:
+#define hash_for_each_size(name, bits, bkt, node, obj, member)
On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
BTW, you can also go a step further and remove the need to close with double
}},
with something like:
#define do_for_each_ftrace_rec(pg, rec)
\
for (pg = ftrace_pages_start, rec =
On 09/04/2012 06:17 PM, Steven Rostedt wrote:
On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
BTW, you can also go a step further and remove the need to close with double
}},
with something like:
#define do_for_each_ftrace_rec(pg, rec)
\
On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
On 09/04/2012 06:17 PM, Steven Rostedt wrote:
On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
BTW, you can also go a step further and remove the need to close with
double }},
with something like:
#define
On 09/04/2012 09:59 PM, Steven Rostedt wrote:
On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
On 09/04/2012 06:17 PM, Steven Rostedt wrote:
On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
BTW, you can also go a step further and remove the need to close with
double }},
with
On Tue, 2012-09-04 at 22:51 +0100, Pedro Alves wrote:
On 09/04/2012 09:59 PM, Steven Rostedt wrote:
On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
On 09/04/2012 06:17 PM, Steven Rostedt wrote:
On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
BTW, you can also go a step
On 09/04/2012 11:41 PM, Steven Rostedt wrote:
Ah, I missed the condition with the rec == pg-records[pg-index]. But
if ftrace_pages_start is NULL, the rec = pg-records[pg-index] will
fault.
Right.
You could do something like rec = pg ? pg-records[pg-index] : NULL,
Right.
but IIRC, the
On Tue, 2012-09-04 at 23:58 +0100, Pedro Alves wrote:
Not true. The comma operator introduces a sequence point. It's the comma
that separates function parameters that doesn't guarantee ordering.
Bah! C language is almost as confusing as English.
-- Steve
--
To unsubscribe from this list:
* Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote:
> * Sasha Levin (levinsasha...@gmail.com) wrote:
> > On 08/28/2012 12:11 PM, Mathieu Desnoyers wrote:
> > > * Sasha Levin (levinsasha...@gmail.com) wrote:
> > >> On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
> > >>> * Tejun Heo
* Sasha Levin (levinsasha...@gmail.com) wrote:
> On 08/28/2012 12:11 PM, Mathieu Desnoyers wrote:
> > * Sasha Levin (levinsasha...@gmail.com) wrote:
> >> On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
> >>> * Tejun Heo (t...@kernel.org) wrote:
> Hello,
>
> On Sat, Aug 25, 2012 at
On 08/28/2012 12:11 PM, Mathieu Desnoyers wrote:
> * Sasha Levin (levinsasha...@gmail.com) wrote:
>> On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
>>> * Tejun Heo (t...@kernel.org) wrote:
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> Thats the thing,
* Sasha Levin (levinsasha...@gmail.com) wrote:
> On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
> > * Tejun Heo (t...@kernel.org) wrote:
> >> Hello,
> >>
> >> On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> >>> Thats the thing, the amount of things of things you can do with a
On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
> * Tejun Heo (t...@kernel.org) wrote:
>> Hello,
>>
>> On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
>>> Thats the thing, the amount of things of things you can do with a given
>>> bucket
>>> is very limited. You can't add entries to
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 08/28/2012 12:11 PM, Mathieu Desnoyers wrote:
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
* Tejun Heo (t...@kernel.org) wrote:
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha
* Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote:
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 08/28/2012 12:11 PM, Mathieu Desnoyers wrote:
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
* Tejun Heo (t...@kernel.org)
On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
* Tejun Heo (t...@kernel.org) wrote:
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
Thats the thing, the amount of things of things you can do with a given
bucket
is very limited. You can't add entries to any point
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
* Tejun Heo (t...@kernel.org) wrote:
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
Thats the thing, the amount of things of things you can do with a given
bucket
is
On 08/28/2012 12:11 PM, Mathieu Desnoyers wrote:
* Sasha Levin (levinsasha...@gmail.com) wrote:
On 08/25/2012 06:24 AM, Mathieu Desnoyers wrote:
* Tejun Heo (t...@kernel.org) wrote:
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
Thats the thing, the amount of things of
* Tejun Heo (t...@kernel.org) wrote:
> Hello,
>
> On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> > Thats the thing, the amount of things of things you can do with a given
> > bucket
> > is very limited. You can't add entries to any point besides the head
> > (without
> > walking
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
> Thats the thing, the amount of things of things you can do with a given bucket
> is very limited. You can't add entries to any point besides the head (without
> walking the entire list).
Kinda my point. We already have all
>> Why do we need hash_head/hash_for_each_head()? I haven't stumbled on a place
>> yet
>> that needed direct access to the bucket itself.
>
> Because whole hash table walking is much less common and we can avoid
> another full set of iterators.
I don't agree. Out of 32 places which now use a
Hello,
On Fri, Aug 24, 2012 at 10:53:45PM +0200, Sasha Levin wrote:
> Yup, but we could be using the same API for dynamic non-resizable and static
> if
> we go with the DECLARE/hash_init. We could switch between them (and other
> implementations) without having to change the code.
I think it's
On 08/24/2012 10:33 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
>>> If this implementation is about the common trivial case, why not just
>>> have the usual DECLARE/DEFINE_HASHTABLE() combination?
>>
>> When we add the dynamic
Hello, Sasha.
On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
> > If this implementation is about the common trivial case, why not just
> > have the usual DECLARE/DEFINE_HASHTABLE() combination?
>
> When we add the dynamic non-resizable support, how would DEFINE_HASHTABLE()
> look?
On 08/24/2012 09:59 PM, Tejun Heo wrote:
> 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
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
On 08/23/2012 10:04 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Thu, Aug 23, 2012 at 02:24:32AM +0200, Sasha Levin wrote:
>>> I think the almost trivial nature of hlist hashtables makes this a bit
>>> tricky and I'm not very sure but having this combinatory explosion is
>>> a bit dazzling when
On 08/23/2012 10:04 PM, Tejun Heo wrote:
Hello, Sasha.
On Thu, Aug 23, 2012 at 02:24:32AM +0200, Sasha Levin wrote:
I think the almost trivial nature of hlist hashtables makes this a bit
tricky and I'm not very sure but having this combinatory explosion is
a bit dazzling when the same
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
On 08/24/2012 09:59 PM, Tejun Heo wrote:
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
Hello, Sasha.
On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
If this implementation is about the common trivial case, why not just
have the usual DECLARE/DEFINE_HASHTABLE() combination?
When we add the dynamic non-resizable support, how would DEFINE_HASHTABLE()
look?
Hmmm?
On 08/24/2012 10:33 PM, Tejun Heo wrote:
Hello, Sasha.
On Fri, Aug 24, 2012 at 10:11:55PM +0200, Sasha Levin wrote:
If this implementation is about the common trivial case, why not just
have the usual DECLARE/DEFINE_HASHTABLE() combination?
When we add the dynamic non-resizable support,
Hello,
On Fri, Aug 24, 2012 at 10:53:45PM +0200, Sasha Levin wrote:
Yup, but we could be using the same API for dynamic non-resizable and static
if
we go with the DECLARE/hash_init. We could switch between them (and other
implementations) without having to change the code.
I think it's
Why do we need hash_head/hash_for_each_head()? I haven't stumbled on a place
yet
that needed direct access to the bucket itself.
Because whole hash table walking is much less common and we can avoid
another full set of iterators.
I don't agree. Out of 32 places which now use a hashtable
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
Thats the thing, the amount of things of things you can do with a given bucket
is very limited. You can't add entries to any point besides the head (without
walking the entire list).
Kinda my point. We already have all the
* Tejun Heo (t...@kernel.org) wrote:
Hello,
On Sat, Aug 25, 2012 at 12:59:25AM +0200, Sasha Levin wrote:
Thats the thing, the amount of things of things you can do with a given
bucket
is very limited. You can't add entries to any point besides the head
(without
walking the entire
Hello, Sasha.
On Thu, Aug 23, 2012 at 02:24:32AM +0200, Sasha Levin wrote:
> > I think the almost trivial nature of hlist hashtables makes this a bit
> > tricky and I'm not very sure but having this combinatory explosion is
> > a bit dazzling when the same functionality can be achieved by simply
Hello, Sasha.
On Thu, Aug 23, 2012 at 02:24:32AM +0200, Sasha Levin wrote:
I think the almost trivial nature of hlist hashtables makes this a bit
tricky and I'm not very sure but having this combinatory explosion is
a bit dazzling when the same functionality can be achieved by simply
Hi Tejun,
On 08/22/2012 08:01 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
>> +#define DEFINE_HASHTABLE(name, bits)
>> \
>> +struct hlist_head name[HASH_SIZE(bits)];
>
> Shouldn't this be
On 23/08/12 04:01, Tejun Heo wrote:
> Hello, Sasha.
>
> On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
>> +#define DEFINE_HASHTABLE(name, bits)
>> \
>> +struct hlist_head name[HASH_SIZE(bits)];
>
> Shouldn't this be something like the
Hello, Sasha.
On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
> +#define DEFINE_HASHTABLE(name, bits) \
> + struct hlist_head name[HASH_SIZE(bits)];
Shouldn't this be something like the following?
#define DEFINE_HASHTABLE(name, bits)
Hello, Sasha.
On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
+#define DEFINE_HASHTABLE(name, bits) \
+ struct hlist_head name[HASH_SIZE(bits)];
Shouldn't this be something like the following?
#define DEFINE_HASHTABLE(name, bits)
On 23/08/12 04:01, Tejun Heo wrote:
Hello, Sasha.
On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
+#define DEFINE_HASHTABLE(name, bits)
\
+struct hlist_head name[HASH_SIZE(bits)];
Shouldn't this be something like the following?
Hi Tejun,
On 08/22/2012 08:01 PM, Tejun Heo wrote:
Hello, Sasha.
On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
+#define DEFINE_HASHTABLE(name, bits)
\
+struct hlist_head name[HASH_SIZE(bits)];
Shouldn't this be something like
86 matches
Mail list logo
