linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi@vger.kernel.org,
	Matthew Garrett <matthew.garrett@nebula.com>,
	Jeremy Kerr <jk@ozlabs.org>,
	Matt Fleming <matt.fleming@intel.com>
Subject: Re: efivarfs and writev() support
Date: Tue, 17 Mar 2015 15:46:30 +0000	[thread overview]
Message-ID: <20150317154630.GA25605@codeblueprint.co.uk> (raw)
In-Reply-To: <C20D75CF-FA82-43E5-BF70-E4E30E1D987B@holtmann.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

  reply	other threads:[~2015-03-17 15:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-08 22:24 efivarfs and writev() support Marcel Holtmann
2015-03-11 13:42 ` Matt Fleming
2015-03-11 15:12   ` Marcel Holtmann
2015-03-12  6:34     ` Al Viro
2015-03-12 14:58       ` Marcel Holtmann
2015-03-12 17:03         ` Al Viro
2015-03-14 16:33           ` Marcel Holtmann
2015-03-17 15:46             ` Matt Fleming [this message]
2015-03-17 16:03               ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150317154630.GA25605@codeblueprint.co.uk \
    --to=matt@codeblueprint.co.uk \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=matt.fleming@intel.com \
    --cc=matthew.garrett@nebula.com \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).