summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorMatt Fleming <matt.fleming@intel.com>2013-02-02 15:22:24 +0000
committerMatt Fleming <matt.fleming@intel.com>2013-04-17 08:30:06 +0100
commit4423d779af2a8f1fbd01aeca5c56522efce7262f (patch)
tree7a3b39ccdd4022075324545b49237c86d36bfe1a /.mailmap
parentd5abc7c1050ab2b9556a4bf21626cd74e83cd086 (diff)
efivars: Keep a private global pointer to efivars
Some machines have an EFI variable interface that does not conform to the UEFI specification, e.g. CONFIG_GOOGLE_SMI. Add the necessary code so that it's only possible to use one implementation of EFI variable operations at runtime. This allows us to keep a single (file-scope) global pointer 'struct efivars', which simplifies access. This will hopefully dissuade developers from accessing the generic operations struct directly in the future, as was done in the efivarfs and pstore code, thereby allowing future code to work with both the generic efivar ops and the google SMI ops. This may seem like a step backwards in terms of modularity, but we don't need to track more than one 'struct efivars' at one time. There is no synchronisation done between multiple EFI variable operations, and according to Mike no one is using both the generic EFI var ops and CONFIG_GOOGLE_SMI simultaneously, though a single kernel build _does_ need to able to support both. It also helps to clearly highlight which functions form the core of the efivars interface - those that require access to __efivars. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions