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:01:05 +0800
From:	Greg KH <greg@...ah.com>
To:	Mike Waychison <mikew@...gle.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 04:24:34PM -0800, Mike Waychison wrote:
> This patchset applies to v2.6.38-rc2.
> 
> The following series implements support for interfaces exposed by
> google's servers' firmware.
> 
> We'd like to have these small drivers included as they are required for
> proper use of the kernel in our infrastructure.  They may not seem like
> much, but a lot of our health automation as well as our human debugging
> efforts are dependent on the functionality herein.
> 
> I'm pretty happy with the way this patchset looks and would like to ask
> that they be merged at some point if there aren't any big objections.
> Getting these in the public Linux tree would bring us closer to being
> able to easily test kernels as they are released.
> 
> I wasn't certain who to send these patches to, please advise if I should
> be CCing anyone else.

I can take these, once they get all worked out, as I think I'm still the
de-facto firmware maintainer.

> [1] and [5] are the only ones that touch the 'core' kernel.
> 
> 
>    - [1] adds a notifier_block that is called on Oops.

This seems like a duplication of the existing infrastructure we already
have for getting notified of oopses.

>    - [2] introduces CONFIG_GOOGLE_FIRMWARE which all Google firmware
>      drivers can depend upon.
> 
>    - [3] and [4] are drivers we use that are ready for inclusion.  [3]
>      communicates with our EFI images via an SMI handshake.  [4] works
>      with our older BIOSes to construct a log of reboot reasons.
> 
>    - [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.  What happens when someone
else wants this and you get dueling "firsts"?

thanks,

greg k-h
--
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/