[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100620214550.GE32241@openwall.com>
Date: Mon, 21 Jun 2010 01:45:50 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: 1.7.6-jumbo-2
On Wed, Jun 16, 2010 at 09:43:21PM -0600, RB wrote:
> On Wed, Jun 16, 2010 at 18:31, Solar Designer <solar@...nwall.com> wrote:
> > I think it'd be helpful to have
> > john-1.7.5-fullmpi-8-after-jumbo2.diff.gz updated to apply after
> > 1.7.6-jumbo-3. In fact, I'd like to see it in a form suitable for
> > merging into the jumbo patch
>
> Interesting, I thought you would have preferred to see it go. The
> reason I'd originally re-designed it to apply before the jumbo patch
> was that the jumbo patch is a moving target and it was easier to get
> one MPI patch that applied to a clean tree and avoided conflicts with
> anything the jumbo was doing.
...but then people would be applying the jumbo patch and would get those
same conflicts anyway. I think most of the people who want MPI support
also want the jumbo patch.
> Combining it into the jumbo patch should be relatively trivial.
Right.
> Heck, I personally would love to see the jumbo itself broken out into
> a series of non-conflicting, bisectable patches instead of the
> snowball it's become, but don't know enough about the individual
> contributons to disentangle them without spending serious time. I
> also have my suspicions that there are going to be guaranteed
> conflicts since the core code wasn't necessarily designed with
> patching in mind.
Not only that. There are also "conflicts" between components that were
combined and integrated into the jumbo patch. For example, several
contributed "formats" would bring MD5 implementations with them,
including duplicate ones (across the multiple "formats"). When
integrating them into the jumbo patch, we made them use shared code
where reasonable. If we separate them, we'd either have conflicts
(these separate patches would each bring in the same things) or we'd
need to solve this differently - e.g., by having a "new APIs" patch to
be applied prior to the "new formats" patches. This gets complicated.
It's just not worth it given the overall quality of the jumbo patch.
The effort may be better invested into improving JtR itself. Yet the
jumbo patch needs to stay around and maintained.
> Of course, there are those on the other end of the
> spectrum that would rather see the whole patching business go away,
> not made even more "complex".
That's also true.
> > that is, with proper #ifdef's to allow
> > for both non-MPI and MPI-enabled builds from the same source tree.
>
> I think that can be done, but the build process will have to be hooked
> as well, since the MPI patch uses mpicc instead of gcc.
I think it'll be a few Makefile lines to uncomment to use MPI, just like
I have for OpenMP now.
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.
