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-next>] [day] [month] [year] [list]
Date:	Mon, 24 Jan 2011 16:24:34 -0800
From:	Mike Waychison <mikew@...gle.com>
To:	Greg KH <greg@...ah.com>, torvalds@...ux-foundation.org
Cc:	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: [PATCH v1 0/6] google firmware support

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.

Thanks,

Patchset summary
================

[1] and [5] are the only ones that touch the 'core' kernel.


   - [1] adds a notifier_block that is called on Oops.

   - [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.

   - [6] uses the bits in [5].  It discovers the BIOSes memory log and
     prepends it to the dmesg during bootup.

Diffstat
========

 drivers/firmware/Kconfig             |   10 
 drivers/firmware/Makefile            |    2 
 drivers/firmware/google/Kconfig      |   39 +
 drivers/firmware/google/Makefile     |    4 
 drivers/firmware/google/bootlog.c    |  884 +++++++++++++++++++++++++++++++++
 drivers/firmware/google/gsmi.c       |  931 +++++++++++++++++++++++++++++++++++
 drivers/firmware/google/memconsole.c |  136 +++++
 fs/compat_ioctl.c                    |    7 
 include/linux/gsmi.h                 |  120 ++++
 include/linux/kernel.h               |    3 
 include/linux/miscdevice.h           |    1 
 include/linux/notifier.h             |    3 
 include/linux/printk.h               |    5 
 kernel/panic.c                       |   15 
 kernel/printk.c                      |   55 ++
 15 files changed, 2214 insertions(+), 1 deletion(-)

ChangeLog:
==========
- v1
   - Initial public send-out.
--
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