linux-kernel - Re: [PATCH v1 0/6] google firmware support

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]

Date:	Tue, 25 Jan 2011 11:58:27 -0800
From:	Mike Waychison <mikew@...gle.com>
To:	Greg KH <greg@...ah.com>
Cc:	torvalds@...ux-foundation.org, San Mehat <san@...gle.com>,
	Aaron Durbin <adurbin@...gle.com>,
	Duncan Laurie <dlaurie@...gle.com>,
	linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>
Subject: Re: [PATCH v1 0/6] google firmware support

On Mon, Jan 24, 2011 at 7:01 PM, Greg KH <greg@...ah.com> wrote:
> On Mon, Jan 24, 2011 at 04:24:34PM -0800, Mike Waychison wrote:
>>
>>    - [5] prepares for [6] by introducing prepend_to_dmesg() which
>>      allows drivers to prepend pre-kernel messages to the dmesg at
>>      bootup.
>
> That seems "rude".  Why can't you just pick out from the kernel log the
> data you need when it gets printed?  This seems like you feel your code
> should always get a "First Post!" message.

Well, the use case we have is that we prepend all the bios output (and
anything emitted by option roms and boot loaders via int 10h).  This
typically runs in the 100+ lines of output.

Basically, everything the user sees on the console after power up is
available to him in the dmesg.  We did this out of convenience as it
makes for a good looking log :)

That said, it's dmesg, and we don't build automation on anything in
there if we can help it.  I can move this memory console dump
elsewhere (/sys/firmware/log ?)

>  What happens when someone
> else wants this and you get dueling "firsts"?

No idea :)

Originally I had something a little different for getting this done:
I had introduced a weak symbol called something like
"arch_dmesg_fixup()" that could be made strong in the architecture
code somewhere (in my case, it was in this driver).    That sort of
pattern would allow us to enforce having only one 'first post'
callback :)

Anyhow, let me know what you think about /sys/firmware/log or similar.
--
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/