From: Frans Klaver <fransklaver@gmail.com>
To: Darren Hart <dvhart@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Corentin Chary <corentin.chary@gmail.com>,
Rafael Wysocki <rafael.j.wysocki@intel.com>,
acpi4asus-user <acpi4asus-user@lists.sourceforge.net>,
platform-driver-x86 <platform-driver-x86@vger.kernel.org>,
linux-kernel@vger.kernel.org,
linux-acpi <linux-acpi@vger.kernel.org>,
"H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: [PATCH 10/13] eeepc-laptop: compare proper return values in get_cpufv
Date: Tue, 16 Sep 2014 23:40:37 +0200 [thread overview]
Message-ID: <20140916214037.GB23674@gmail.com> (raw)
In-Reply-To: <20140916212715.GB6856@vmdeb7>
On Tue, Sep 16, 2014 at 02:27:15PM -0700, Darren Hart wrote:
>
> - When reading and writing sysfs device attribute files, avoid dependency
> on specific error codes wherever possible. This minimizes coupling to
> the error handling implemementation within the kernel.
>
> In general, failures to read or write sysfs device attributes shall
> propogate errors wherever possible. Common errors include, but are not
> limited to:
>
> -EIO: The read or store operation is not supported, typically returned by
> the sysfs system itself if the read or store pointer is NULL.
>
> -ENXIO: The read or store operation failed
>
> Error codes will not be changed without good reason, and should a change
> to error codes result in user-space breakage, it will be fixed, or the
> the offending change will be reverted.
sysfs-rules.txt is written for user space? In that case, reverting the
change is as much a fix as patching it.
>
> Userspace applications can, however, expect the format and contents of
> the attribute files to remain consistent in the absence of a version
> attribute change in the context of a given attributes.
...attribute.
That's it for the nit-picking.
Frans
next prev parent reply other threads:[~2014-09-16 21:40 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 23:06 [PATCH 00/13] eeepc-laptop cleanups Frans Klaver
2014-09-12 23:06 ` [PATCH 01/13] eeepc-laptop: coding style: fix indentation Frans Klaver
2014-09-12 23:06 ` [PATCH 02/13] eeepc-laptop: coding style: add curly braces around else compound Frans Klaver
2014-09-12 23:06 ` [PATCH 03/13] " Frans Klaver
2014-09-15 19:41 ` Darren Hart
2014-09-15 19:58 ` Frans Klaver
2014-09-12 23:06 ` [PATCH 04/13] eeepc-laptop: use symbolic permissions in device attributes Frans Klaver
2014-09-12 23:06 ` [PATCH 05/13] eeepc-laptop: use DEVICE_ATTR to instantiate device_attributes Frans Klaver
2014-09-12 23:28 ` Greg Kroah-Hartman
2014-09-14 22:05 ` Frans Klaver
2014-09-12 23:06 ` [PATCH 06/13] eeepc-laptop: pull out ACPI_STORE_FUNC and ACPI_SHOW_FUNC macros Frans Klaver
2014-09-12 23:06 ` [PATCH 07/13] eeepc-laptop: make disp attribute really write-only Frans Klaver
2014-09-15 20:00 ` Darren Hart
2014-09-15 20:01 ` Frans Klaver
2014-09-12 23:06 ` [PATCH 08/13] eeepc-laptop: pull out SENSOR_STORE_FUNC and SENSOR_SHOW_FUNC macros Frans Klaver
2014-09-12 23:06 ` [PATCH 09/13] eeepc-laptop: make fan1_input really read-only Frans Klaver
2014-09-12 23:06 ` [PATCH 10/13] eeepc-laptop: compare proper return values in get_cpufv Frans Klaver
2014-09-15 21:49 ` Darren Hart
2014-09-15 21:51 ` Greg Kroah-Hartman
2014-09-15 21:55 ` Frans Klaver
2014-09-16 11:54 ` Frans Klaver
2014-09-16 20:52 ` Darren Hart
2014-09-16 21:10 ` Frans Klaver
2014-09-16 23:39 ` Darren Hart
2014-09-16 21:27 ` Darren Hart
2014-09-16 21:33 ` Greg Kroah-Hartman
2014-09-16 21:40 ` Frans Klaver [this message]
2014-09-16 21:43 ` Darren Hart
2014-09-17 10:34 ` Henrique de Moraes Holschuh
2014-09-17 11:57 ` Frans Klaver
2014-09-17 16:12 ` Darren Hart
2014-09-12 23:06 ` [PATCH 11/13] eeepc-laptop: propagate errors from get_cpufv Frans Klaver
2014-09-15 21:50 ` Darren Hart
2014-09-12 23:06 ` [PATCH 12/13] eeepc-laptop: store_cpufv: return error if set_acpi fails Frans Klaver
2014-09-12 23:06 ` [PATCH 13/13] eeepc-laptop: return -ENXIO if acpi getter or setter fails Frans Klaver
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=20140916214037.GB23674@gmail.com \
--to=fransklaver@gmail.com \
--cc=acpi4asus-user@lists.sourceforge.net \
--cc=corentin.chary@gmail.com \
--cc=dvhart@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
/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.