lkml.org 
[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/4] printk: Allocate kernel log buffer earlier

* Mike Travis <travis@sgi.com> wrote:

> Yinghai Lu wrote:

> > please check updated patch...
> >
> > with the memblock change, you don't need to change acpi SRAT handling etc any
> > more.
>
> I had to debug a weird ACPI -> Node mapping last week and the
> "improved" SRAT messages helped that considerably. It was
> far easier to spot which Node didn't have the correct assignments.
> I'd submit that patch even without needing fewer (like 512 lines
> max instead of 4096 lines max) bytes in the log buffer.

I agree that better compressed output generally makes sense - you just need to solve
the ugliness aspect of it. (or get Len's Acked-by to add that code to drivers/acpi/)

Nevertheless doing this via memblock is obviously more important, as it solves the
early printk log overrun problem once and for all.

> Let's move on to far more important problems.

That's not the threshold for upstream inclusion though. (at least for patches that
we process via the -tip tree)

If you add crap to a single hardware driver then only that hardware is affected, but
if you change the way the printk buffer is allocated it is *very important*, because
like every single kernel message is affected by it.

So we scale up our review threshold with the importance of the piece of code
affected.

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-03-01 08:45    [W:3.589 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site