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

[Greg KH]

On Thu, Jan 27, 2011 at 03:41:06PM -0800, Mike Waychison wrote:
> 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!).

It should just be passing that data straight to the hardware and not
trying to process the data at all, right?  If not, then it needs to be
fixed and not use the firmware binary interface...

thanks,

greg k-h
--
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/