Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753487AbbDTD2l (ORCPT ); Sun, 19 Apr 2015 23:28:41 -0400 Received: from mga14.intel.com ([192.55.52.115]:45763 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752359AbbDTD2h convert rfc822-to-8bit (ORCPT ); Sun, 19 Apr 2015 23:28:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,607,1422950400"; d="scan'208";a="716089875" From: "Kweh, Hock Leong" To: Matt Fleming , Greg Kroah-Hartman , Andy Lutomirski CC: Ming Lei , "Ong, Boon Leong" , LKML , "linux-efi@vger.kernel.org" , Sam Protsenko , Peter Jones , Roy Franz , Borislav Petkov Subject: RE: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware Thread-Topic: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware Thread-Index: AQHQdrzO9Y2+ZGg6U0KLDsR6juvZY51N4NhA//+pEQCAAVzbQIAB0EYAgAANNQCAA67xIA== Date: Mon, 20 Apr 2015 03:28:32 +0000 Message-ID: References: <1429004697-28320-1-git-send-email-hock.leong.kweh@intel.com> <1429004697-28320-3-git-send-email-hock.leong.kweh@intel.com> <20150414140914.GE5989@kroah.com> <20150415131906.GC21491@kroah.com> <20150417134924.GB19794@kroah.com> <20150417143640.GB3671@codeblueprint.co.uk> In-Reply-To: <20150417143640.GB3671@codeblueprint.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3549 Lines: 80 > -----Original Message----- > From: Matt Fleming [mailto:matt@codeblueprint.co.uk] > 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/