lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080918105728.GF20967@elte.hu>
Date:	Thu, 18 Sep 2008 12:57:28 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jason Baron <jbaron@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] loglevel=pci:8,acpi:8,apic=8 support v6


* H. Peter Anvin <hpa@...or.com> wrote:

> 8) The ability to accessed filtered messages a posteori (via dmesg), 
> which is something we currently take for granted.
>
> This *is* the fundamental difference between what Yinghai has now and 
> both your stuff and Yinghai's original proposal.  Not producing the 
> additional messages at all is inherently cheaper, sometimes *much* 
> cheaper, but it obviously means the information is not accessible at 
> all.

which is what we really want. If a bootup fails, the user has to repeat 
the bootup at least once with a verbosity level increased and with 
(hopefully) some sort of log capture facility attached.

So the point would be, if the user specified loglevel=all, we would get 
really comprehensive, one-stop-shop output.

> At the moment, I would argue that the fact that dmesg is, in effect, 
> more verbose than the kernel itself is a good thing; it makes dmesg 
> dumps more useful.

yes - but log messages not showing up on the physical console is already 
a task that is solved via regular loglevels. printks are being removed 
because even printing to the dmesg can be expensive (vsprintf is not the 
cheapest of functions, and most of dmesg shows up in the syslog and 
people want a clear, default, not too verbose output for that).

so the main feature of these patches is that we can cut out too verbose 
information by default, and we can reactivate it with a single central 
switch (and a repeated bootup - which has to be done anyway). Everything 
else is already solved via either traditional loglevels or pr_debug() 
based, build-time facilities.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ