Messages in this thread | | | Date | Wed, 27 Jun 2012 08:09:39 +0200 | From | Ingo Molnar <> | Subject | Re: cosmetic printk() issue with lockdep warning in arch/x86/kernel/alternative.c |
| |
(Cc:-ed a more interested folks and lkml, as this really matters to more people than just me)
* Kay Sievers <kay@vrfy.org> wrote:
> mind moving "fixing up alternatives" in: > arch/x86/kernel/alternative.c:431 > down to where really happens something, or whatever other solution > fits, maybe it can be removed today ... > > The CPU code in: > arch/x86/kernel/smpboot.c:654 > tries to print continuation lines, which look weird with the > prefix-less lockdep warning that gets merged into the former line when > lockdep is enabled: > > [ 0.053070] lockdep: fixing up alternatives. > [ 0.054003] Booting Node 0, Processors #1lockdep: fixing up alternatives. > [ 0.128995] #2lockdep: fixing up alternatives. > [ 0.203985] #3lockdep: fixing up alternatives. > [ 0.278972] #4lockdep: fixing up alternatives. > [ 0.353960] #5lockdep: fixing up alternatives. > [ 0.427948] #6lockdep: fixing up alternatives. > [ 0.501937] #7 Ok. > [ 0.575952] Brought up 8 CPUs
We could certainly change the lockdep printouts - but I'm really not sure it's wise to fight those kinds of printk() usage patterns:
Piecemail wise printouts are handy and natural as they follow actual code flow. As the code progresses so do the continued printk()s get progressed. We use single-line printouts to not use up too much screen real estate during bootup.
So ... why not do what I suggested very, very early on: don't touch printk screen output itself *AT ALL* - keep it simple and direct, don't add complexity to the pathway of kernel code trying to communicate a kernel bug to the user.
Instead solve your needs by simply tracing printk() calls and the resulting strings [with a string event - I think Steve posted an RFC patch for that early on - apply that patch and recover the events - we could build-in this portion of tracing whenever CONFIG_PRINTK is enabled to make sure the facility is always available] and reconstruct the lines and the full ASCII-string events in user-space: if PID,CPU is traced and there's one record per printk() call then it's *trivial* to reconstruct 99.9% of the printk lines in the user-space code that receives the trace events.
Keep /proc/kmsg and don't change it much - but trace printk() calls form your new systemd code. WHY don't you use that approach? It's actually totally sensible, useful, it keeps the printk status quo in place, improves other usecases and can be done using existing facilities...
Thanks,
Ingo
| |