linux-kernel - Re: [PATCH] fix up perfmon to build on -mm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071109213829.GC28276@kroah.com>
Date:	Fri, 9 Nov 2007 13:38:29 -0800
From:	Greg KH <greg@...ah.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	eranian@....hp.com, perfmon@...ali.hpl.hp.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix up perfmon to build on -mm

On Fri, Nov 09, 2007 at 12:06:27PM -0800, Andrew Morton wrote:
> On Tue, 6 Nov 2007 16:34:54 -0800
> Greg KH <greg@...ah.com> wrote:
> 
> > Here's a patch against my current tree that gets the perfmon code
> > building and hopefully working.
> 
> Unfortunately I still haven't merged perfmon due to recently-occurring
> minor conflicts with Tony's ia64 tree and more major recently-occurring
> conflicts with the x86 tree.
> 
> There's not really a lot which Stephane can practically do about this -
> normally I'll just get down and fix stuff like this up.  But the impression
> I get from various people is that the perfmon tree in its present form
> would not be a popular merge.
> 
> The impression which people have (and I admit to sharing it) is that
> there's just too much stuff in there and it might not all be justifiable. 
> But I suspect that people have largely forgotten what is in there, and why
> it is in there.
> 
> We really need to get this ball rolling, and that will require a sustained
> effort from more people than just Stephane.  I suppose as a starting point
> we could yet again review the existing patches, please.  People will mainly
> concentrate upon the changelogging to understand which features are being
> proposed and why, so that submission should describe these things pretty
> carefully: what are the features and why do we need each of them.

Is there some way to rebase these patches/git tree to be a bit more easy
to review?  Right now there are over 75 patches in the tree and many (if
not most) can be removed by merging them with previous patches.

If someone could break this stuff down into reviewable pieces, it would
go a very long way toward making it acceptable.

Is there any way to just provide a basic framework that everyone can
agree on and then add on more stuff as time goes on?  Do we have to have
every different processor/arch with support to start with?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/