Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965503AbbDVPZN (ORCPT ); Wed, 22 Apr 2015 11:25:13 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:52342 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965450AbbDVPZJ (ORCPT ); Wed, 22 Apr 2015 11:25:09 -0400 Date: Wed, 22 Apr 2015 16:24:34 +0100 From: One Thousand Gnomes To: James Bottomley Cc: Peter Jones , Andy Lutomirski , 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: <20150422162434.0c701702@lxorguk.ukuu.org.uk> In-Reply-To: <1429715913.2195.22.camel@HansenPartnership.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> <20150422132734.GB12062@redhat.com> <1429715913.2195.22.camel@HansenPartnership.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1390 Lines: 31 > Yes, I think we've all agreed we can do it ... it's now a question of > whether we can stomach the ick factor of actually initiating a > transaction in close ... I'm still feeling queasy. NFS does transactions - including figuring out if the data will fit - on file close. It does that for real data so I'd relax. With hard disks we don't even complete a set of actions on close they just float around for a bit and get committed (but if there is a media failure you lose if you didnt commit them first via fsync etc) > The alternative might be a two file approach (either in sysfs or a mini > custom fs), one for load up data and the other for initiate transaction > with the data errors (like overflow) being returned on the load up file > and the transaction errors being returned on the write that initiates > the transaction. The two file problem then turns into the "which transaction of the two done in parallel" problem. > My architectural sense is that transaction on close, provided we can > make it a more universally accepted idea, has a lot of potential because > it's more intuitive than the two file approach. Agreed Alan -- 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/