linux-kernel - Re: [RFC] B+Tree library V2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090108162429.GA24884@logfs.org>
Date:	Thu, 8 Jan 2009 17:24:29 +0100
From:	Jörn Engel <joern@...fs.org>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] B+Tree library V2

On Thu, 8 January 2009 01:57:21 +0100, Johannes Berg wrote:
> On Sat, 2008-11-01 at 16:59 +0100, Jörn Engel wrote:
> 
> [btree library]
> 
> Alright, back to this. I'm going to need something like the patch below
> (except the update facility, which I thought I needed but then changed
> my mind) which is on top of your patch. Does that look sane?

At first glance it does.  The update looks like someone might need it,
but doesn't have a user yet.  The btree_merge is similar, as I used to
need it, but no longer do.  Maybe #if 0 those two.

> One thing that seems a little odd is requiring a btree_init(), but not
> having a btree_destroy(), but rather requiring managing the mempool in
> the caller (which invariably leads to two mempool pointers being
> required unless callers want to look into the btree struct details)...
> Do you think this is required? Could we have a btree_init/btree_destroy
> instead that take care of the mempool stuff?

Well, I used to have heaps of btrees around and wanted to share the
mempool between all of them.  Not sure if I still do, I believe not.
Will check.

If mempools aren't shared, I agree that encapsulating those bits is much
nicer.

> Another thing that I need is a visitor that deletes _some_ entries. How
> can I do that? Additionally, it would be nice to be able to abort a tree
> walk, when you have determined that you can't continue for whatever
> reason.

If you want to open-code it, you can use btree_lookup_less().  I added
that function sometime last month.  Basically something like this:
	key = btree_last(head, geo);
	while (key) {
		/* do something with key */
		key = btree_lookup_less(head, geo, key);
	}

Maybe it should be renamed to btree_get_prev_key().  I never noticed how
confusing it was because my head was busy with other problems.  The code
is currently burried within my logfs tree:
http://logfs.org/git?p=logfs;a=summary

Will merge it with your patch and respin later tonight or tomorrow...

Jörn

-- 
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/