[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120218160834.GA13525@openwall.com>
Date: Sat, 18 Feb 2012 20:08:34 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: format names for GPU-enabled implementations (was: Recent github patches)
On Sat, Feb 18, 2012 at 07:31:20PM +0400, Solar Designer wrote:
> ... I suspect that many users will be confused - if they
> build using a GPU-enabled make target, they expect the GPU code to be
> used by default (if available for a given hash type at all). Should we
> possibly make this so? And how do we also keep the CPU and alternate
> GPU code compiled in (and available for use as non-default), then?
> Rename those other formats?
>
> Alternatively, should we possibly keep things as they are, but improve
> documentation? Maybe have "make" runs with GPU-enabled targets end with
> a note to the user on how to actually access the GPU functionality -
> very brief instructions and/or a reference to a file like doc/GPU?
Unfortunately, this alternative won't be sufficient for binary builds,
once we have any GPU-enabled binary builds that we distribute. We'd
need to have "john" print something at runtime as well when it has GPU
code in it, is invoked on a GPU-enabled hash type, but without the
proper --format option (so using the CPU only). %-)
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.
