Re: [PATCH v1 3/6] driver: Google EFI SMI

From: Mike Waychison
Date: Thu Jan 27 2011 - 18:41:34 EST

On Wed, Jan 26, 2011 at 5:22 PM, Mike Waychison <mikew@xxxxxxxxxx> wrote:
> On Wed, Jan 26, 2011 at 3:58 PM, Mike Waychison <mikew@xxxxxxxxxx> wrote:
>> On Tue, Jan 25, 2011 at 6:46 PM, Greg KH <greg@xxxxxxxxx> wrote:
>>> So, let me ask, what specifically are you wanting to import/export
>>> to/from the kernel here?  Have you thought about other kernel/user apis
>>> instead of ioctls?  What is forcing you to use ioctls?
>> I'm not sure if you are trying to suggest that there is a better way
>> to solve these problems without actually saying so.  We could probably
>> use a different interface, sure.
> Well, I managed to find efivars.c, and it seems like I can probably
> massage it to do what I want as several of the calls I'd like to
> export to userland mirror portions of the EFI runtime services page.
> That won't take care of all of the firmware calls I'd like to export,
> but it's a start.

I've spent the last few hours looking at efivars.c and working out how
I can refactor it to reuse all the kobject bits it uses. Does anybody
use this thing though?

I can't believe I was just lectured for crappy ABI when this thing
takes a binary packed struct on write() and process it:
- without regard to write length, and
- in a way that isn't compatible across compat (both DataSize and
Status are unsigned long!).

struct efi_variable {
efi_char16_t VariableName[1024/sizeof(efi_char16_t)];
efi_guid_t VendorGuid;
unsigned long DataSize;
__u8 Data[1024];
efi_status_t Status;
__u32 Attributes;
} __attribute__((packed));

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at