[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150310154000.GD1208@fenchurch.internal.datastacks.com>
Date: Tue, 10 Mar 2015 11:40:00 -0400
From: Peter Jones <pjones@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Matt Fleming <matt@...sole-pimps.org>,
"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
Sam Protsenko <semen.protsenko@...aro.org>,
Ming Lei <ming.lei@...onical.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Ong, Boon Leong" <boon.leong.ong@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>
Subject: Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
> >> 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.
--
Peter
--
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