From: "Brian J. Watson" <Brian.J.Watson@compaq.com>
To: Daniel Phillips <phillips@bonn-fries.net>, Larry McVoy <lm@bitmover.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Common hash table implementation
Date: Fri, 20 Jul 2001 17:24:03 -0700 [thread overview]
Message-ID: <3B58CBA3.BD2C194@compaq.com> (raw)
In-Reply-To: <01071815464209.12129@starship>
Daniel Phillips wrote:
>
> On Wednesday 18 July 2001 03:34, Larry McVoy wrote:
> > We've got a fairly nice hash table interface in BitKeeper that we'd
> > be happy to provide under the GPL. I've always thought it would be
> > cool to have it in the kernel, we use it everywhere.
> >
> > http://bitmover.com:8888//home/bk/bugfixes/src/src/mdbm
Thanks, Larry. Your hashing functions are much more sophisticated than
the simple modulo operator I've been using for hashing by inode
number.
> I think the original poster was thinking more along the lines of a
> generic insertion, deletion and lookup interface, which we are now
> doing in an almost-generic way in a few places. Once place that is
> distinctly un-generic is the buffer hash, for no good reason that I
> can see. This would be a good starting point for a demonstration.
>
Daniel's correct. I'm hashing function agnostic, but would like some
common code to simplify the management of a hash table.
Richard Guenther sent the following link to his own common hashing
code, which makes nice use of pseudo-templates:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/glame/glame/src/include/hash.h?rev=1.5&content-type=text/plain
A few things I would consider changing are:
- ditching the pprev pointer
- encapsulating the next pointer inside a struct hash_head_##FOOBAR
- stripping out the hard-coded hashing function, and allowing the
user to provide their own
All the backslashes offend my aesthetic sensibility, but the
preprocessor provides no alternative. ;)
--
Brian Watson | "The common people of England... so
Linux Kernel Developer | jealous of their liberty, but like the
Open SSI Clustering Project | common people of most other countries
Compaq Computer Corp | never rightly considering wherein it
Los Angeles, CA | consists..."
| -Adam Smith, Wealth of Nations,
1776
mailto:Brian.J.Watson@compaq.com
http://opensource.compaq.com/
next prev parent reply other threads:[~2001-07-21 0:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-18 0:57 Common hash table implementation Brian J. Watson
2001-07-18 1:34 ` Larry McVoy
2001-07-18 13:46 ` Daniel Phillips
2001-07-21 0:24 ` Brian J. Watson [this message]
2001-07-21 20:25 ` Daniel Phillips
2001-07-22 10:18 ` Richard Guenther
2001-07-23 14:36 ` Daniel Phillips
2001-07-22 16:37 ` Larry McVoy
2001-07-23 14:24 ` Daniel Phillips
2001-07-22 23:34 ` Eyal Lebedinsky
2001-07-24 12:57 ` Daniel Phillips
2001-07-22 2:23 ` Rusty Russell
2001-07-24 12:28 ` Daniel Phillips
2001-07-18 9:48 ` Richard Guenther
[not found] <oupitgqjxoi.fsf@pigdrop.muc.suse.de>
2001-07-20 22:32 ` Brian J. Watson
2001-07-21 22:57 ` Daniel Phillips
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=3B58CBA3.BD2C194@compaq.com \
--to=brian.j.watson@compaq.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
--cc=phillips@bonn-fries.net \
/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.