Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751540AbbD2VjU (ORCPT ); Wed, 29 Apr 2015 17:39:20 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38154 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750883AbbD2VjQ (ORCPT ); Wed, 29 Apr 2015 17:39:16 -0400 Message-ID: <1430343554.2189.30.camel@HansenPartnership.com> Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware From: James Bottomley To: Andy Lutomirski Cc: "Kweh, Hock Leong" , Peter Jones , Greg Kroah-Hartman , Matt Fleming , Ming Lei , "Ong, Boon Leong" , LKML , "linux-efi@vger.kernel.org" , Sam Protsenko , Roy Franz , Borislav Petkov , Al Viro , Linux FS Devel Date: Wed, 29 Apr 2015 14:39:14 -0700 In-Reply-To: References: <20150415131906.GC21491@kroah.com> <20150417134924.GB19794@kroah.com> <20150417143640.GB3671@codeblueprint.co.uk> <20150420144323.GA7261@kroah.com> <20150421075620.GA11000@kroah.com> <1429665679.2207.44.camel@HansenPartnership.com> <20150422132734.GB12062@redhat.com> <1429715913.2195.22.camel@HansenPartnership.com> <1429798187.2170.3.camel@HansenPartnership.com> <1429888575.2182.20.camel@HansenPartnership.com> <1430174136.2314.49.camel@HansenPartnership.com> <1430175112.2314.56.camel@HansenPartnership.com> <1430343304.2189.25.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2676 Lines: 57 On Wed, 2015-04-29 at 14:36 -0700, Andy Lutomirski wrote: > On Wed, Apr 29, 2015 at 2:35 PM, James Bottomley > wrote: > > On Wed, 2015-04-29 at 11:23 +0000, Kweh, Hock Leong wrote: > >> I agree with James. Due to different people may have different needs. But > >> from our side, we would just like to have a simple interface for us to upload > >> the efi capsule and perform update. We do not have any use case or need > >> to get info from QueryCapsuleUpdate(). Let me give a suggestion here: > >> please allow me to focus on deliver this simple loading interface and > >> upstream it. Then later whoever has the actual use case or needs on the ioctl > >> implementation, he or she could enhance base on this simple loading interface. > >> What do you guys think? > >> > >> Let me summarize the latest design idea: > >> - No longer leverage on firmware class but use misc device > >> - Do not use platform device but use device_create() > >> - User just need to perform "cat file.bin > /sys/.../capsule_loader" in the shell > >> - File operation functions include: open(), read(), write() and flush() > >> - Perform mutex lock in open() then release the mutex in flush() for avoiding > >> race condition / concurrent loading > >> - Perform the capsule update and error return at flush() function > >> > >> Is there anything I missed? Any one still have concern with this idea? > >> Thanks for providing the ideas as well as the review. > > > > I think that's pretty much it. > > > > Why don't you let me construct a straw man patch. It's going to be a > > bit controversial because it involves adding flush operations to sysfs > > and kernfs, slicing apart firmware_class.c to extract the transaction > > handling stuff and creating an new efi update capsule file which makes > > use of it. > > > > Once we have code, we at least have something more concrete to argue > > over. > > Would it be worth checking whether busybox is also okay with it first? > (Sorry to be a naysayer.) > > It would be a shame if we do all this to keep the userspace footprint > light and then it doesn't work for non-coreutils userspace. I don't think so, because we can fix busybox if it's a problem. The embedded people wanting this control the tool space, so they can decide to use the fixed version. So yes, someone should check and fix busybox cat if broken, but no, it's not a blocker. James -- 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/