linux-kernel - Re: [PATCH][RFC] exception processing in early boot

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20060830134644.GA20129@1wt.eu>
Date:	Wed, 30 Aug 2006 15:46:44 +0200
From:	Willy Tarreau <w@....eu>
To:	Sean <seanlkml@...patico.ca>
Cc:	Andi Kleen <ak@...e.de>, davej@...hat.com, pageexec@...email.hu,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC] exception processing in early boot

On Wed, Aug 30, 2006 at 10:00:15AM -0400, Sean wrote:
> On Wed, 30 Aug 2006 15:16:12 +0200
> Willy Tarreau <w@....eu> wrote:
> 
> > That's already what I'm doing, and yes, it is *that* hard. We're literally
> > speaking about *thousands* of patches. It's as difficult to find one patch
> > within 2.6 git changes as it is to find a useful mail in the middle of 99%
> > spam. This is not because of GIT but because of the number of changes.
> 
> Willy,
> 
> The git-cherry command might be useful for you in this situation.  It will
> show you all the patches in one branch that have been merged in an upstream
> branch, and those that haven't.  Not sure if it's perfect for your situation,
> but may be worth a look.

I've already used it (it's what I was using when to maintain the 2.4-hf
tree in parallel to Marcelo's mainline). But it's useful when you have
*a few* patches. I'm really speaking about *thousands* of patches that
get merged into 2.6 every few months and this is what makes the job difficult.
Not to mention that they also get merged in 2.6-mm in advance, or that
sometimes they are obsoleted and/or replaced by something else.

Clearly, I'm not going to track all 2.6 patch by patch to maintain 2.4 !

The most scalable workflow is distributed, and should be oriented towards
push and not pull. We just have to ensure that *someone* takes care of
each patch and tracks it up to its merge.

> Sean

Cheers,
Willy

-
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/