Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Jul 2013 22:53:50 +0400
From: Solar Designer <>
Subject: Re: bug: GPU use in CPU-only formats

Claudio, magnum -

On Tue, Jul 02, 2013 at 10:01:15PM -0300, Claudio Andr? wrote:
> > > Can't we do all initial "opening" of anything GPU-related in the
> > > format's init(), if the format is GPU-enabled, and not any sooner?
> > > 
> > > Perhaps there's some implementation difficulty that I am missing.
> It is possible, but if the user ask for -dev=7, i have to check if there
> is such device, counting all available devices in each platform (this is
> why we need to do more than only parse the command line). On unstable,
> -device is always related to only one platform (no need to care about
> other platforms). On bleeding, -device is a sequential number.

Why did we introduce this unneeded(?) complexity?  Was anything wrong
with unstable's numbering of devices?  Why don't we revert to it now?

I think we should revert, unless you somehow convince me otherwise.

> Seems to me this kind of check is always done at initialization. Is it
> possible to give an error message and exit using the JtR way if this
> check is moved to init()? 

As currently defined, init() "can't fail", so we have to terminate the
process right from there if it does fail.  This means e.g. printing a
message and calling misc.c's error().  That's not pretty, yet it's
better than accessing GPU in a CPU-only invocation of john.


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.