On 08/04/2012 02:05 AM, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin wrote:
>>
>> The problem with that code was that it doesn't work with dynamically
>> allocated hashtables, or hashtables that grow/shrink.
>
> Sure. But once you have that kind of complexity, why would yo
On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin wrote:
>
> The problem with that code was that it doesn't work with dynamically
> allocated hashtables, or hashtables that grow/shrink.
Sure. But once you have that kind of complexity, why would you care
about the trivial cases?
Linus
--
Hello,
On Fri, Aug 03, 2012 at 04:47:47PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo wrote:
> >
> > I suppose you mean unsized. I remember this working. Maybe I'm
> > confusing it with zero-sized array. Hmm... gcc doesn't complain about
> > the following. --std=c
Hi Linus,
On 08/04/2012 01:47 AM, Linus Torvalds wrote:
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
>
> I really think all the extra complexity and overhead is
On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo wrote:
>
> I suppose you mean unsized. I remember this working. Maybe I'm
> confusing it with zero-sized array. Hmm... gcc doesn't complain about
> the following. --std=c99 seems happy too.
Ok, I'm surprised, but maybe it's supposed to work if you do
On Fri, Aug 03, 2012 at 03:29:10PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo wrote:
> >
> > I actually meant an enclosing struct. When you're defining a struct
> > member, simply putting the storage after a struct with var array
> > should be good enough. If that d
On Fri, Aug 3, 2012 at 3:23 PM, Tejun Heo wrote:
>
> I actually meant an enclosing struct. When you're defining a struct
> member, simply putting the storage after a struct with var array
> should be good enough. If that doesn't work, quite a few things in
> the kernel will break.
The unsigned
On 08/04/2012 12:23 AM, Tejun Heo wrote:
> Hello,
>
> On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
>> On 08/03/2012 11:48 PM, Tejun Heo wrote:
>>> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
I forgot to comment on that one, sorry.
If we put hash entr
Hello,
On Sat, Aug 04, 2012 at 12:20:02AM +0200, Sasha Levin wrote:
> On 08/03/2012 11:48 PM, Tejun Heo wrote:
> > On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> >> I forgot to comment on that one, sorry.
> >>
> >> If we put hash entries after struct hash_table we don't take the
>
On 08/03/2012 11:48 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
>> I forgot to comment on that one, sorry.
>>
>> If we put hash entries after struct hash_table we don't take the
>> bits field size into account, or did I miss something?
>
> So, if
Hello,
On Fri, Aug 03, 2012 at 11:41:34PM +0200, Sasha Levin wrote:
> I forgot to comment on that one, sorry.
>
> If we put hash entries after struct hash_table we don't take the
> bits field size into account, or did I miss something?
So, if you do the following,
struct {
Hello, Sasha.
On Fri, Aug 03, 2012 at 11:36:49PM +0200, Sasha Levin wrote:
> On 08/03/2012 11:30 PM, Tejun Heo wrote:
> The function definition itself is just a macro, for example:
>
> #define MM_SLOTS_HASH_CMP(mm_slot, obj) ((mm_slot)->mm == (obj))
It seems like it would make things more
On 08/03/2012 11:30 PM, Tejun Heo wrote:
> 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,
On 08/03/2012 11:30 PM, Tejun Heo wrote:
>> 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 differ
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
> > en
On 08/03/2012 07:15 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Fri, Aug 03, 2012 at 04:23:02PM +0200, Sasha Levin wrote:
>> +#define DEFINE_STATIC_HASHTABLE(n, b)
>> \
>> +static struct hash_table n = { .bits = (b), \
>> +
On Fri, 2012-08-03 at 16:23 +0200, Sasha Levin wrote:
> This hashtable implementation is using hlist buckets to provide a simple
> hashtable to prevent it from getting reimplemented all over the kernel.
>
> +static void hash_add(struct hash_table *ht, struct hlist_node *node, long
> key)
> +{
>
Ooh, one more thing. Comments please.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hello, Sasha.
On Fri, Aug 03, 2012 at 04:23:02PM +0200, Sasha Levin wrote:
> +#define DEFINE_STATIC_HASHTABLE(n, b)
> \
> + static struct hash_table n = { .bits = (b), \
> + .buckets = { [0 ... ((1 << (b)) - 1)] = HLIST_HE
This hashtable implementation is using hlist buckets to provide a simple
hashtable to prevent it from getting reimplemented all over the kernel.
Signed-off-by: Sasha Levin
---
include/linux/hashtable.h | 75 +
1 files changed, 75 insertions(+), 0 del
20 matches
Mail list logo
