All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
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 09:03:38 -0700	[thread overview]
Message-ID: <48E5761B-8142-4CDE-9AAD-BCD70C34BC13@holtmann.org> (raw)
In-Reply-To: <20150317154630.GA25605@codeblueprint.co.uk>

Hi Matt,

>> 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.

meaning only writev() with a single vector is supported.

>> 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).

I have no problems with these semantics, but it means you need to add support for .write_iter since otherwise multiple vectors will not work. And really think that is better than forcing userspace to work around this limitation.

As I mentioned earlier, for me it was really obvious to use a vectored write for EFI variables. That just made sense to me. So seeing it not working caused confusion.

Regards

Marcel


WARNING: multiple messages have this Message-ID (diff)
From: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Matthew Garrett
	<matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>,
	Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	Matt Fleming
	<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: efivarfs and writev() support
Date: Tue, 17 Mar 2015 09:03:38 -0700	[thread overview]
Message-ID: <48E5761B-8142-4CDE-9AAD-BCD70C34BC13@holtmann.org> (raw)
In-Reply-To: <20150317154630.GA25605-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>

Hi Matt,

>> 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.

meaning only writev() with a single vector is supported.

>> 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).

I have no problems with these semantics, but it means you need to add support for .write_iter since otherwise multiple vectors will not work. And really think that is better than forcing userspace to work around this limitation.

As I mentioned earlier, for me it was really obvious to use a vectored write for EFI variables. That just made sense to me. So seeing it not working caused confusion.

Regards

Marcel

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

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-08 22:24 efivarfs and writev() support Marcel Holtmann
2015-03-08 22:24 ` Marcel Holtmann
2015-03-11 13:42 ` Matt Fleming
2015-03-11 15:12   ` Marcel Holtmann
2015-03-11 15:12     ` Marcel Holtmann
2015-03-12  6:34     ` Al Viro
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-14 16:33             ` Marcel Holtmann
2015-03-17 15:46             ` Matt Fleming
2015-03-17 15:46               ` Matt Fleming
2015-03-17 16:03               ` Marcel Holtmann [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=48E5761B-8142-4CDE-9AAD-BCD70C34BC13@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.