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

quoted text
> On Wed, Sep 17, 2008 at 10:47:54AM +0200, Ingo Molnar wrote:
> > 
> > * 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.
> 
> Or just leave ACPI:, PCI:. Tags are already in place in some sense.
> 
> > 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.
> 
> Simply nice looking log is irrational. I can understand if by default 
> messages do not fit into printk buffer before userspace can save them. 
> This is indeed harmful and loses information.
> 
> OTOH, all these loglevel games ultimately lead to missed messages (by 
> design). I remember myself wasting time debugging wrong path simply 
> because box wasn't booted with ignore_loglevel and critical debugging 
> printk wasn't on serial console, but only in dmesg.
> 
> So, in some cases useless information will not be shown, but in some 
> absolutely critical information will not be shown.

yes, i had that happen too, and i am quite sure that the most sensible 
way out is to provide a _single_ point for users to enable 'all things 
debug'. I.e. a "loglevel=debug" (or loglevel=all) boot parameter.

Instead of the current list of zillions of ad-hoc switchlets that are 
scattered all around the kernel. Tell me, within 10 seconds, which one 
of these are the correct options and which ones are typos:

 lapic
 lapic=verbose 
 apic=debug
 ignore-loglevel 
 initcalldebug
 early_printk=vga
 ignoreloglevel
 debug
 verbose
 ignore_loglevel
 initcall_debug
 apic=verbose
 initcall=debug
 earlyprintk=vga

(i'm willing to bet a good beer that you probably have not found the 
right solution in time :-)

People dont really want to individually enable pci or apic or smp 
debugging or whatnot - when it's about boot debugging they (and we) just 
want something really verbose. (_Sometimes_ we want more accurate 
filters for runtime debugging, especially if something can produce a log 
of continuing printks during userspace bootup - but that is an 
afterthought IMO.)

with such a facility in place we could just hide all non-essential 
messages by default, and have the perpetual possibility to get a verbose 
bootup without users having to rebuild their (often distro-built) 
kernel.

The only ongoing work would be to occasionally convert a stray 
informational printk that seemed to be useful during early development 
to a subsystem printk that hides it by default. The printk is not 
actually _lost_ and is utmost trivial to activate it again, should the 
need arise - which loss is why the "get rid of printks" patches are 
opposed most of the time.

So i think we'll hit multiple birds with the same stone.

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/