[lkml]   [2015]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Tue, Mar 10, 2015 at 8:40 AM, Peter Jones <> wrote:
>> >> So, for the sysfs interface, let's not allow loading from /lib. Let's
>> >> not require a userland tool. Let's just do,
>> >>
>> >> # echo /path/to/my/awesome/capsule.bin > /sys/../capsule
>> >
>> >>
>> >> and be done with it.
>> >>
>> >> Hmmm?
>> >
>> > I assume you're implying a) the capsule header with the guid is embedded
>> > in the .bin there already, and b) one contiguous write(2) with error
>> > reporting coming through something like vars.c's efi_status_to_err()?
>> >
>> > If so, yes, I prefer this API.
>> >
>> Is using a char device really so bad? I have a "simple_char" that
>> makes this really easy that's pending review.
> As long as there's straightforward propagation of the EFI_STATUS return
> from UpdateCapsule() back, sysfs file vs char device makes very little
> difference to me. Either way it's open(), write(), close(). Using the
> runtime firmware upload interface designed for wifi and scsi devices is
> the part I don't really like.

I'm not 100% happy with write(2) (which is all we have in sysfs) for
two reasons:

1. If we write a file name, eww. That's more complicated, requires
temporary files, has annoying mount namespace issues, etc.

2. If we write the full contents, we need to do it in a single call to
write. That means that we can't use cat, which mostly defeats the
purpose. In fact, using cat could be actively harmful.


 \ /
  Last update: 2015-03-10 17:01    [W:0.089 / U:7.056 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site