Date:	Tue, 21 Apr 2015 09:56:20 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>,
	Andy Lutomirski <luto@...capital.net>,
	Ming Lei <ming.lei@...onical.com>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Sam Protsenko <semen.protsenko@...aro.org>,
	Peter Jones <pjones@...hat.com>,
	Roy Franz <roy.franz@...aro.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi
 firmware

On Tue, Apr 21, 2015 at 03:23:55AM +0000, Kweh, Hock Leong wrote:
> > -----Original Message-----
> > From: Greg Kroah-Hartman [mailto:gregkh@...uxfoundation.org]
> > Sent: Monday, April 20, 2015 10:43 PM
> > 
> > On Mon, Apr 20, 2015 at 03:28:32AM +0000, Kweh, Hock Leong wrote:
> > > Regarding the 'reboot require' status, is it critical to have a 1 to 1 status
> > match
> > > with the capsule upload binary? Is it okay to have one sysfs file note to tell
> > the
> > > overall status (for example: 10 capsule binaries uploaded but one require
> > > reboot, so the status shows reboot require is yes)? I am not here trying to
> > argue
> > > anything. I am just trying to find out what kind of info is needed but the
> > sysfs
> > > could not provide.
> > >
> > > Please imagine if your whole Linux system (kernel + rootfs) has to fit into
> > 6MB
> > > space and you don't even have the gcc compiler included into the package.
> > > I believe in this environment, kernel interface + shell command is the only
> > > interaction that user could work with.
> > 
> > Why would you have to have gcc on such a system?  Why is that a
> > requirement for having an ioctl/char interface?
> 
> This is my logic:
> - Besides writing a C program (for example), I am not aware any shell script
>   could perform an ioctl function call. This led me to if I don't have an execution
>   binary then I need a compiler to compile the source to execution binary.

You would have built it on a separate machine, like the one you used to
build your kernel and other binary packages you are running.

> - For embedded product as mentioned above, not all vendors willing to carry
>   the userland tool when they are struggling to fit into small memory space.
>   Yet, you may say this tool would not eat up a lot of space compare to others.
>   But when the source of this tool being upstream-ed to the tools/ kernel tree,
>   we cannot stop people to contribute and make the tool more features support,
>   eventually the embedded product may need to drop the tool.

So because someday in the future someone might make the code that is
open source too big for us to use, we are going to reject the idea
today?  That really doesn't make any sense.

> > And if you only have 6Mb of space, you don't have UEFI, sorry, there's
> > no way that firmware can get that small.
> 
> Actually there is. Quark is one of the examples. The kernel + rootfs take
> up 6MB and the UEFI consume only 2MB, so total size 8MB in the spi chip.
> If you have an Intel Galileo board, you don't need any mass storage (SD & USB),
> you are able to boot to Linux console.

Does Galieleo support this UEFI feature?  If so, great, how big is a
binary that can read a file and write the data using an ioctl?

thanks,

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