linux-kernel - Re: [PATCH] apci: dump slit

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0809122323050.13819@apollo.tec.linutronix.de>
Date:	Fri, 12 Sep 2008 23:44:32 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andi Kleen <andi@...stfloor.org>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] apci: dump slit

On Fri, 12 Sep 2008, Andi Kleen wrote:
> On the other hand there's quite some other information dumped
> at boot that could be cut out. e.g. It doesn't really make 
> much sense to dump the cache information of each CPU at boot
> when that information can easily be gotten from user space
> later.

You're assuming that you ever reach user space, which is a pretty dumb
assumption.

I prefer to have a detailed view of the machine when I have to look at
a bug report where the machine does _NOT_ reach user space.
 
> I personally was also always sceptical of some of the
> more detailed new memory map dumping, like those "nosave
> memory" or the early reservation/early node/add_active_range output.
> It's pretty much a direct function of the e820 map dumped earlier.
> Also node information has now the dubious distinction to be 
> the most redundantly dumped kernel information of all.

Bla, bla, bla. 

This code was reworked significantly and every information which is
given about the various decisions made are useful to debug problems. I
prefer a more noisy startup over some silent fuckup when a problem
hits.

We had enough trouble to decode silent "fixups" which failed
miserably.

Thanks,

	tglx
--
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/