[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTim27Y+TKa54jhC1VuqXzjEzX150ysGoUKNJrBmk@mail.gmail.com>
Date: Thu, 27 Jan 2011 15:41:06 -0800
From: Mike Waychison <mikew@...gle.com>
To: Greg KH <greg@...ah.com>
Cc: torvalds@...ux-foundation.org, 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: Re: [PATCH v1 3/6] driver: Google EFI SMI
On Wed, Jan 26, 2011 at 5:22 PM, Mike Waychison <mikew@...gle.com> wrote:
> On Wed, Jan 26, 2011 at 3:58 PM, Mike Waychison <mikew@...gle.com> wrote:
>> On Tue, Jan 25, 2011 at 6:46 PM, Greg KH <greg@...ah.com> 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@...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