RE: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware
-Original Message- From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Sent: Monday, April 20, 2015 10:43 PM On Mon, Apr 20, 2015 at 03:28:32AM +, 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. - 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. 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. Thanks Regards, Wilson -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware
On Mon, Apr 20, 2015 at 03:28:32AM +, 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? And if you only have 6Mb of space, you don't have UEFI, sorry, there's no way that firmware can get that small. Btw, just to make sure I get it correctly, is misc device refer to the device that created by misc_register() from drivers/char/misc.c and not asked to put this kernel module under drivers/misc/* location, right? Yes, use misc_register() And Matt mentioned including the source into tools/* in kernel tree. I have a question: Is this tool can be compiled during kernel compilation and eventually auto included into the rootfs package? Sorry, I am new to OS creation and maybe this is stupid question. If you ask to build it as part of the configuration, yes, it can be built. See how the tools are build as part of the kernel tree for more information about this. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware
On Fri, 2015-04-17 at 15:49 +0200, Greg Kroah-Hartman wrote: On Thu, Apr 16, 2015 at 09:42:31AM +, Kweh, Hock Leong wrote: -Original Message- From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Sent: Wednesday, April 15, 2015 9:19 PM On Wed, Apr 15, 2015 at 11:32:29AM +, Kweh, Hock Leong wrote: -Original Message- From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Sent: Tuesday, April 14, 2015 10:09 PM On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote: From: Kweh, Hock Leong hock.leong.k...@intel.com Introducing a kernel module to expose capsule loader interface for user to upload capsule binaries. This module leverage the request_firmware_direct_full_path() to obtain the binary at a specific path input by user. Example method to load the capsule binary: echo -n /path/to/capsule/binary /sys/devices/platform/efi_capsule_loader/capsule_loader Ick, why not just have the firmware file location present, and copy it to the sysfs file directly from userspace, instead of this two-step process? Err I may not catch your meaning correctly. Are you trying to say that you would prefer the user to perform: cat file.bin /sys/.../capsule_loader instead of echo -n /path/to/binary /sys//capsule_laoder Yes. What's the namespace of your /path/to/binary/ and how do you know the kernel has the same one when it does the firmware load call? By just copying the data with 'cat', you don't have to worry about namespace issues at all. Hi Greg, Let me double confirm that I understand your concern correctly. You are trying to tell that some others module may use a 'same' namespace to request the firmware but never release it. Then when our module trying to request the firmware by passing in the 'same' namespace, I will get the previous data instead of the current binary data from the path I want. Yes. Hmm I believe this concern also apply to all the current request_firmware APIs right? And I believe the coincidence to have 'same' file name namespace would be higher than full path namespace. Not really, the kernel namespace is what matters at that point in time. And maybe it does matter, I haven't thought through all of the issues. But passing a path from userspace, to the kernel, to have the kernel turn around again and use that path is full of nasty consequences at times due to namespaces, let's avoid all of that please. So just to clarify this, namespaces are designed not to cause a problem here, provided the operation is handled correctly (this is key; it is easy do design operations which will screw up no end if done wrongly). The file name to object translation is handled by the mount name space, which is the operative one of the process doing the echo. For a longstanding object (i.e. one which will exist beyond the call to the system of the current process) you need either to convert to the actual underlying object (usually a file descriptor) which has an existence independent of the namespace (and perform all the necessary security validations before returning control back to userspace, so they occur within all the namespace constraints of the calling process), or store sufficient information to redo whatever operation you need to within the namespace (the former is by far preferred for long lived operations). James -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
