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

[Mike Waychison]

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/