> Sloppy and inconsistent code also leaves a lasting negative impression
> on newbie developers. I've heard quite a few opinions about Linux's code
> base being a lot less consistent (and hence harder to understand) than
Do you think they did refer to code style (as in indentation etc.) here?
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > The kernel process request that _all_ contributors run their
> > > > patches through checkpath.pl and fix the problems.
> > >
> > > That's new. When and by whom was that rule been introduced? And
> > > with what rationale?
> >
> > Documentation/
On Friday 04 January 2008 21:34:15 Thomas Gleixner wrote:
> On Fri, 4 Jan 2008, Andi Kleen wrote:
> > > The kernel process request that _all_ contributors run their patches
> > > through checkpath.pl and fix the problems.
> >
> > That's new. When and by whom was that rule been introduced? And wit
On Fri, 4 Jan 2008, Andi Kleen wrote:
> > The kernel process request that _all_ contributors run their patches
> > through checkpath.pl and fix the problems.
>
> That's new. When and by whom was that rule been introduced? And with what
> rationale?
Documentation/SubmitChecklist
> Even checkpatc
On Friday 04 January 2008 16:02:37 Pekka Enberg wrote:
> Hi Andi,
>
> On Jan 4, 2008 4:39 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > The kernel process request that _all_ contributors run their patches
> > > through checkpath.pl and fix the problems.
> >
> > That's new. When and by whom was t
Hi Andi,
On Jan 4, 2008 4:39 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The kernel process request that _all_ contributors run their patches
> > through checkpath.pl and fix the problems.
>
> That's new. When and by whom was that rule been introduced? And with what
> rationale?
Not be new to a
> The kernel process request that _all_ contributors run their patches
> through checkpath.pl and fix the problems.
That's new. When and by whom was that rule been introduced? And with what
rationale?
Even checkpatch.pl itself says to only fix the warnings that make sense.
This one didn't. And
On Fri, 4 Jan 2008, Andi Kleen wrote:
> On Friday 04 January 2008 10:42:17 Thomas Gleixner wrote:
> > On Thu, 3 Jan 2008, Andi Kleen wrote:
> > > This makes a significant difference in boot up performance on AMD SimNow!
> > > Also I expect it to be a little faster on native systems too because a
>
On Friday 04 January 2008 10:42:17 Thomas Gleixner wrote:
> On Thu, 3 Jan 2008, Andi Kleen wrote:
> > This makes a significant difference in boot up performance on AMD SimNow!
> > Also I expect it to be a little faster on native systems too because a smp
> > switch does a lot of text_poke()s which
On Thu, 3 Jan 2008, Andi Kleen wrote:
> This makes a significant difference in boot up performance on AMD SimNow!
> Also I expect it to be a little faster on native systems too because a smp
> switch does a lot of text_poke()s which each synchronize the pipeline.
Please run your patches through c
On VMs implemented using JITs that cache translated code changing the lock
prefixes is a quite costly operation that forces the JIT to throw away and
retranslate a lot of code.
Previously a SMP kernel would rewrite the locks once for each CPU which
is quite unnecessary. This patch changes the
11 matches
Mail list logo