Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752868AbbDVReP (ORCPT ); Wed, 22 Apr 2015 13:34:15 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:43175 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751522AbbDVReL (ORCPT ); Wed, 22 Apr 2015 13:34:11 -0400 Message-ID: <1429724049.2195.44.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: Greg KH , Kweh Hock Leong , LKML , Matt Fleming , "Ong, Boon Leong" , "linux-efi@vger.kernel.org" , Ming Lei Date: Wed, 22 Apr 2015 10:34:09 -0700 In-Reply-To: References: <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> <20150420144323.GA7261@kroah.com> <20150421075620.GA11000@kroah.com> <1429665679.2207.44.camel@HansenPartnership.com> <1429669228.2207.46.camel@HansenPartnership.com> <1429678269.18798.9.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: 2546 Lines: 63 On Wed, 2015-04-22 at 09:50 -0700, Andy Lutomirski wrote: > On Apr 21, 2015 9:51 PM, "James Bottomley" > wrote: > > > > On Tue, 2015-04-21 at 20:24 -0700, Andy Lutomirski wrote: > > > On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley > > > wrote: > > > > On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote: > > > >> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley > > > >> wrote: > > > >> > Andy, just on the misc device idea, what about triggering the capsule > > > >> > update from close()? In theory close returns an error code (not sure if > > > >> > most tools actually check this, though). That means we can do the write > > > >> > in chunks but pass it in atomically on the close and cat will work > > > >> > (provided it checks the return code of close). > > > >> > > > >> I thought about this but IIRC cat doesn't check the return value from close. > > > > > > > > It does in my copy (coreutils-8.23) : > > > > > > > > if (!STREQ (infile, "-") && close (input_desc) < 0) > > > > { > > > > error (0, errno, "%s", infile); > > > > ok = false; > > > > } > > > > [...] > > > > if (have_read_stdin && close (STDIN_FILENO) < 0) > > > > error (EXIT_FAILURE, errno, _("closing standard input")); > > > > > > > > > > True, but it's stdout that we care about, not stdin :( > > > > Gosh you're determined to force me to wade through this source code, > > aren't you? That's handled in lib/closeout.c: > > > > /* Close standard output. On error, issue a diagnostic and _exit > > with status 'exit_failure'. > > > > ... > > > > > > The point is that, admittedly much to my surprise, it all looks to be > > handled by cat ... so we could proceed to have the transaction completed > > in close in a misc device (or a sysfs file). > > > > Unless there are any other rabbits you'd like to pull out of the hat? > > No, maybe it's okay, unless there's an issue where the error would > only be returned on the close of the last reference of the struct > file. After all, 'cat foo >/sys/bar' doesn't fully close /sys/bar > until after cat exits. No, cat handles that too. It has an atexit() handler for closing stdout. 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/