Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966703AbbDVQuy (ORCPT ); Wed, 22 Apr 2015 12:50:54 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:33502 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965980AbbDVQuw (ORCPT ); Wed, 22 Apr 2015 12:50:52 -0400 MIME-Version: 1.0 In-Reply-To: <1429678269.18798.9.camel@HansenPartnership.com> 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> From: Andy Lutomirski Date: Wed, 22 Apr 2015 09:50:30 -0700 Message-ID: Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware To: James Bottomley Cc: Greg KH , Kweh Hock Leong , LKML , Matt Fleming , "Ong, Boon Leong" , "linux-efi@vger.kernel.org" , Ming Lei Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2312 Lines: 57 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. --Andy -- 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/