[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93b02c16a6f03aa56ea1f904b99b7427@smtp.hushmail.com>
Date: Wed, 08 Jul 2015 04:15:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on GPU
On 2015-07-06 10:25, Solar Designer wrote:
> 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().
This is implemented now (without the "int self_test") in 38af431
(formats in e19d87e).
Agnieszka, you will likely have to adopt your code a little for it to
work at all.
magnum
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.
