> -----Original Message----- > From: Matt Fleming [mailto:matt@xxxxxxxxxxxxxxxxxxx] > Sent: Friday, April 17, 2015 10:37 PM > > On Fri, 17 Apr, at 03:49:24PM, Greg KH wrote: > > > > 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. > > Oh crap. The namespace issue is a good point and not something I'd > thought of at all. > > At this point, I think we've really run out of objections to Andy's > suggestion of implementing this as a misc device, right? > > The concern I had about userspace tooling can partly be addressed by > including the source in tools/ in the kernel tree. So provided we do > that, I'm happy enough to see this implemented as a misc device because > the other options we've explored just haven't panned out. > > Objections? > > -- > Matt Fleming, Intel Open Source Technology Center Hi Greg, Matt & Andy, Wait .... wait a minute. I am lost. I think I have missed something. Let me summarize the message I got from the email threads. ========================================================= Greg:- Recommends to use "cat file.bin > /sys/.../capsule_loader" due to there is concern on kernel namespace with this submitted design which using the request firmware API. Andy:- Prefer to have an interface that could return the error code and suggested char device where the ioctl can meet the purpose. Matt:- Prefer to use kernel interface only as embedded world may not want to include userland tool. ========================================================== I think I have missed somewhere why not using "cat file.bin > /sys/.../loader" and now change to misc device. Is it because the ioctl could return a custom error code (for example: platform not supported, capsule header error) where the "cat file.bin > /sys/.../loader" interface cannot do? Hmm ...... 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. 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? 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. Thanks & Regards, Wilson -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
