Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756915AbbDVN1l (ORCPT ); Wed, 22 Apr 2015 09:27:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57719 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753149AbbDVN1j (ORCPT ); Wed, 22 Apr 2015 09:27:39 -0400 Date: Wed, 22 Apr 2015 09:27:34 -0400 From: Peter Jones To: Andy Lutomirski Cc: James Bottomley , Greg Kroah-Hartman , "Kweh, Hock Leong" , Matt Fleming , Ming Lei , "Ong, Boon Leong" , LKML , "linux-efi@vger.kernel.org" , Sam Protsenko , Roy Franz , Borislav Petkov Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware Message-ID: <20150422132734.GB12062@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2543 Lines: 76 On Tue, Apr 21, 2015 at 06:58:58PM -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. I checked this for the use case we'd talked about before - gnu cat /does/ check the error code, but it's easy to miss how, because coreutils code has some good ole' gnu-code complexity. It'll print the strerror() representation, but it always exits with 1 as the error code. Specifically the close on the output is handled by this: --------------- initialize_main (&argc, &argv); set_program_name (argv[0]); setlocale (LC_ALL, ""); bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE); /* Arrange to close stdout if we exit via the case_GETOPT_HELP_CHAR or case_GETOPT_VERSION_CHAR code. Normally STDOUT_FILENO is used rather than stdout, so close_stdout does nothing. */ atexit (close_stdout); /* Parse command line options. */ while ((c = getopt_long (argc, argv, "benstuvAET", long_options, NULL)) --------------- Which in turn does: --------------- void close_stdout (void) { if (close_stream (stdout) != 0 && !(ignore_EPIPE && errno == EPIPE)) { char const *write_error = _("write error"); if (file_name) error (0, errno, "%s: %s", quotearg_colon (file_name), write_error); else error (0, errno, "%s", write_error); _exit (exit_failure); } if (close_stream (stderr) != 0) _exit (exit_failure); } --------------- exit_failure is a global from libcoreutils.a which cat never changes from the default, so it's always 1. (And of course error() is coreutils' own implementation rather than glibc's because hey maybe you're not using glibc, but still, it's there.) So it's /annoying/ to propagate the error from there programatically, but it can work. -- Peter -- 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/