All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lingzhu Xiang <lxiang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Matt Fleming
	<matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
Subject: Re: [PATCH 3/3] selftests/efivarfs: Add create-read test
Date: Mon, 28 Jan 2013 19:25:48 +0800	[thread overview]
Message-ID: <5106603C.5050309@redhat.com> (raw)
In-Reply-To: <1359240460.11991.960193311372.3.gpush@pororo>

On 01/27/2013 06:47 AM, Jeremy Kerr wrote:
> +	if (!(rc < 0 && errno == EIO)) {
> +		fprintf(stderr, "Reading a new var should return -EIO\n");

What does the -EIO imply for reading a known empty file?

The file is empty. There is nothing to be read. No IO should actually 
happens.
The variable doesn't exist in nvram. What is the error? This won't make 
sense
for userspace.

Empty variable never exists in nvram per spec. Userspace doesn't need an 
extra
EIO to figure out this known fact. In the meantime, user would wonder if
something else has gone wrong? Returning zero for reading an empty file can
reserve EIO for something more informational.

Maybe at this time we just leave it as it is for other reasons. But at least
I don't think it's a good idea to mandate this behavior.

  reply	other threads:[~2013-01-28 11:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-26 22:47 [PATCH 0/3] selftests: Add efivarfs tests Jeremy Kerr
2013-01-26 22:47 ` [PATCH 1/3] selftests: Add tests for efivarfs Jeremy Kerr
2013-01-26 22:47 ` [PATCH 2/3] selftests/efivarfs: Add empty file creation test Jeremy Kerr
2013-01-26 22:47 ` [PATCH 3/3] selftests/efivarfs: Add create-read test Jeremy Kerr
2013-01-28 11:25   ` Lingzhu Xiang [this message]
     [not found]     ` <5106603C.5050309-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-01-28 12:37       ` Matt Fleming
     [not found]         ` <1359376629.8282.18.camel-ZqTwcBeJ+wsBof6jY8KHXm7IUlhRatedral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-01-28 22:40           ` Jeremy Kerr
     [not found]             ` <5106FE77.3030001-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
2013-01-29 20:18               ` Matt Fleming
2013-01-29  3:30           ` Lingzhu Xiang

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=5106603C.5050309@redhat.com \
    --to=lxiang-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org \
    /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.