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
next prev parent 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.