All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] loglevel=pci:8,acpi:8,apic=8 support v5
Date: Wed, 17 Sep 2008 10:47:54 +0200	[thread overview]
Message-ID: <20080917084754.GC24035@elte.hu> (raw)
In-Reply-To: <20080917073058.GA3770@x200.localdomain>


* Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Wed, Sep 17, 2008 at 12:10:09AM -0700, Yinghai Lu wrote:
> >     KERN_PCI
> >     KERN_ACPI
> > v4: fix some checkpatch error and warning
> > v5: add default with DEFINE_LOGLEVE_SETUP_DEF
> >     KERN_APIC
> > 
> > usage:
> > 	in .h to have
> > 		#define KERN_PCI "<pci>"
> > 	in .c to have
> > 		DEFINE_LOGLEVEL_SETUP(pci, KERN_PCI, "pci:");
> > 	then could use
> > 		printk(KERN_DEBUG KERN_PCI fmt, ...);
> > 	and command line
> > 		loglevel=3,pci:8
> > 
> > you can add different printk to different files of one subsys if you like
> > not just one susbsys one tag, and don't need to update kernel.h to add more tags
> 
> I think all of this is overdesigned and stupid.
> 
> People expecting that loglevels are exactly right so they can calm 
> messages are like security-savvy people who expect all security 
> relevant bugfixes carry CVE tag.
> 
> grep says there are 50757 printk calls, only 32129 of them carry KERN_ 
> tag.
>
> Oh, and new and improved logs:
> 
> 	[    0.340326] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
> 	[    0.340326] pci 0000:00:01.0: PME# disabled
> 	[    0.340326] <pci>PCI: 0000:00:1a.0 reg 20 io port: [dc00, dc1f]
> 	[    0.340413] <pci>PCI: 0000:00:1a.1 reg 20 io port: [e000, e01f]
> 	[    0.340549] <pci>PCI: 0000:00:1a.7 reg 10 32bit mmio: [febffc00, febfffff]
> 		       ^^^^^^^^^
> How this can be an improvement for those who boot with ignore_loglevel,
> I don't know.

the subsystem tags should be cut out by dmesg by default, just like the 
normal <1> tags are cut out.

about your general point: it's valid observations. The idea would be to 
end this never ending unstable conflict of people adding printks for 
debug reasons versus people removing printks who'd like to have a nice 
looking bootup log.

Both point of views are correct in different usecases - and IMO the best 
solution is the consolidation hpa suggested and what Yinghai is working 
towards: to replace all the current ad-hoc debug printouts (with 
different switchlets strewn all across the kernel) with an ASCII based 
generic printk facility and a generic boot line option.

people adding printks without any KERN_ tag is fine - this facility is 
only interesting to subsystems who'd like to make use of it. (core code, 
ec. - the items that have a disproportionate weight in terms of system 
stability, and which thus have a disproportionate need to stay 
debuggable and regression-free)

[ and we also need a dynamic facility to change the filters via debugfs 
  btw - it should be possible to modify these printk filters after 
  bootup, runtime. Many subsystems have debug printks that make sense to 
  enable/disable after the system has booted up. ]

and it's bad and a showstopper if the default output of 'dmesg' 
degrades, like your noticed - those are bugs in the concept and need to 
be fixed.

	Ingo

  reply	other threads:[~2008-09-17  8:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-17  7:10 [PATCH 0/6] loglevel=pci:8,acpi:8,apic=8 support v5 Yinghai Lu
2008-09-17  7:10 ` [PATCH 1/6] add DEFINE_LOGLEVEL_SETUP v6 Yinghai Lu
2008-09-17  7:10 ` [PATCH 2/6] pci: add KERN_PCI Yinghai Lu
2008-09-17  7:10 ` [PATCH 3/6] pci: using printk(KERN_PCI v3 Yinghai Lu
2008-09-17  7:10 ` [PATCH 4/6] acpi: add KERN_ACPI v3 Yinghai Lu
2008-09-17  7:10 ` [PATCH 5/6] apci: dump slit with printk(KERN_ACPI...) Yinghai Lu
2008-09-17  7:10 ` [PATCH 6/6] x86: add KERN_APIC Yinghai Lu
2008-09-17  7:30 ` [PATCH 0/6] loglevel=pci:8,acpi:8,apic=8 support v5 Alexey Dobriyan
2008-09-17  8:47   ` Ingo Molnar [this message]
2008-09-17  9:25     ` Alexey Dobriyan
2008-09-17  9:40       ` Ingo Molnar
2008-09-17 16:23     ` Yinghai Lu
2008-09-17 17:07     ` H. Peter Anvin
2008-09-17 18:10       ` Yinghai Lu
2008-09-17 18:17         ` H. Peter Anvin
2008-09-17 19:05           ` Yinghai Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080917084754.GC24035@elte.hu \
    --to=mingo@elte.hu \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=yhlu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.