Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 7 May 2013 02:46:35 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: OMP fallback for non-systemwide build

On 7 May, 2013, at 2:28 , Solar Designer <solar@...nwall.com> wrote:
> On Tue, May 07, 2013 at 01:30:09AM +0200, magnum wrote:
>> +#ifdef JOHN_SYSTEMWIDE_EXEC
>>  #define OMP_FALLBACK_PATHNAME JOHN_SYSTEMWIDE_EXEC "/" OMP_FALLBACK_BINARY
>>                execv(OMP_FALLBACK_PATHNAME, argv);
>> +#else
>> +#define OMP_FALLBACK_PATHNAME "$JOHN/" OMP_FALLBACK_BINARY
>> +               execv(path_expand(OMP_FALLBACK_PATHNAME), argv);
>> +#endif
> 
> What's the intended use for this?  Are we (or someone) going to
> distribute binary builds that are installable into a user's home
> directory, yet want to include the fallback feature?  Well, maybe.
> However, then we'd want it for CPU fallbacks too, not just OpenMP.

I think many users (including me) that build their own JtR do it non-systemwide. If OMP fallback can still be supported this easily, I think we should do it (at least in Jumbo) and write a brief how-to (this was actually the first time I ever tried the fallback stuff).

For this use, I think CPU fallback is far less important but that would be cool as well.


>> It does work like a champ. Could that relocation of path_init() pose a problem?
> 
> Hopefully not, but I am not sure.  We'd need to relocate it even further
> up - to before CPU_detect_or_fallback() - then enhance that function,
> and test the resulting builds.

I'll play around with that.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ