From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754205AbbCQPqh (ORCPT ); Tue, 17 Mar 2015 11:46:37 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:35151 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753328AbbCQPqf (ORCPT ); Tue, 17 Mar 2015 11:46:35 -0400 Date: Tue, 17 Mar 2015 15:46:30 +0000 From: Matt Fleming To: Marcel Holtmann Cc: Al Viro , Linux Kernel Mailing List , linux-efi@vger.kernel.org, Matthew Garrett , Jeremy Kerr , Matt Fleming Subject: Re: efivarfs and writev() support Message-ID: <20150317154630.GA25605@codeblueprint.co.uk> References: <33E85F72-FCA0-4DF7-B9E1-46D36244FCA3@holtmann.org> <20150311134226.GB24174@codeblueprint.co.uk> <7F5112DD-6998-47D3-B6B9-5618E14E022A@holtmann.org> <20150312063437.GK29656@ZenIV.linux.org.uk> <20150312170344.GN29656@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 14 Mar, at 09:33:00AM, Marcel Holtmann wrote: > > I say we should support writev() on efivarfs. Not supporting it seems > odd especially since that is not documented anywhere. So yes, I am for > adding .write_iter() support and be done with that. Well, as Al has explained it's not that writev() isn't supported, it's that having an iovec vector containing only the 4-byte variable attribute isn't currently supported. Since writev() calls are intended to be atomic, and even though efivarfs gets fed the variable data in chunks we can process it in one go, I think allowing the scenario you describe is fine. > Also please note that even write(,4) and write(,n) does not work > either. You can not write partial entries as it seems. Maybe you are > able to append, but it seems the initial creation of the variable has > to be done with a single write() call. Anything else ends up in a file > with 0 length. Yes, that's by design. I guess it's to prohibit people from creating bogus EFI variables or accidentally deleting variables (a SetVariable() call with length 0 is a delete). -- Matt Fleming, Intel Open Source Technology Center