Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150706082539.GB692@openwall.com>
Date: Mon, 6 Jul 2015 11:25:39 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on GPU

On Mon, Jul 06, 2015 at 01:15:54AM +0200, magnum wrote:
> Thinking loud. Current behavior, for a test run we have:
> reset(NULL)
> self-tests
> benchmarks
> 
> And for a crack run we have:
> reset(NULL)
> self-tests
> reset(db)
> crack mode
> 
> We could change it to always pass "db" to reset(). It could still *be* 
> NULL but we'd never call it with an explicit NULL.
> 
> A test run would be effectively the same. A crack run would become:
> reset(db)
> self-tests
> reset(db)
> crack mode
> 
> This would solve this issue but a side-effect is reset() can no longer 
> tell whether we're about to self-test before a crack or actually run 
> one. For resolving that we could simply change
> 
> void fmt_reset(struct db_main *db);
> 
> ...to
> 
> void fmt_reset(struct db_main *db, int self_test);
> 
> ...and a crack run would change to:
> reset(db, 1)
> self-tests
> reset(db, 0)
> crack mode
> 
> Does this make sense?

Yes, this makes sense to me.  Would we actually need to add this "int
self_test"?  The few formats that care would be able to count the
reset() calls on their own, perhaps with the counter reset on init().

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.