On Fri, 2013-01-25 at 16:36 +0100, Tom Gundersen wrote:
> This registers /sys/firmware/efi{,/efivars} whenever EFI is enabled
> and the system supports it.
>
> This allows
> *) userspace to check for the existence of /sys/firmware/efi as a way
> to determine whether or it is running on an EFI system.
> *) 'mount -t efivarfs none /sys/firmware/efi/efivars' without manually
> loading any modules.
>
> Signed-off-by: Tom Gundersen <[email protected]>
> Cc: Matt Fleming <[email protected]>
> Cc: Kay Sievers <[email protected]>
> Cc: Jeremy Kerr <[email protected]>
> Cc: Matthew Garrett <[email protected]>
> Cc: Chun-Yi Lee <[email protected]>
> Cc: Andy Whitcroft <[email protected]>
> ---
> drivers/firmware/Makefile | 1 +
> drivers/firmware/efisubsys.c | 52
> ++++++++++++++++++++++++++++++++++++++++++++
> drivers/firmware/efivars.c | 30 +++++--------------------
> 3 files changed, 59 insertions(+), 24 deletions(-)
> create mode 100644 drivers/firmware/efisubsys.c
Tom, could you have a go at rebasing this patch on top of the 'chainsaw'
branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/linux.git
Though, instead of drivers/firmware/efisubsys.c just put the core stuff
in drivers/firmware/efi/efi.c. The efivar_entry() API code should
probably be moved to drivers/firmware/efi/variable.c or
drivers/firmware/efi/vars.c, etc. That way, we can finally delete
efivars.c and have all the EFI code under drivers/firmware/efi/.
Make sense?
P.s I ended up dropping your MODULE_ALIAS() patch on this branch because
I feel that moving the efivarfs code into fs/efivarfs is a better way to
fix up the confusion that efivars != efivarfs, plus building fs/efivarfs
as a module results in an efivarfs.ko file ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
