Documentation/sysfs-rules.txt: Add device attribute error code documentation
Provide some entry-level statements about what to expect from sysfs
device attribute read/store return codes, both for users and kernel
developers.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Azael Avalos <coproscefalo@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt
index a5f985e..ce60ffa 100644
--- a/Documentation/sysfs-rules.txt
+++ b/Documentation/sysfs-rules.txt
@@ -161,3 +161,24 @@
the device that matches the expected subsystem. Depending on a specific
position of a parent device or exposing relative paths using "../" to
access the chain of parents is a bug in the application.
+
+- When reading and writing sysfs device attribute files, avoid dependency
+ on specific error codes wherever possible. This minimizes coupling to
+ the error handling implementation within the kernel.
+
+ In general, failures to read or write sysfs device attributes shall
+ propagate 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.
+
+ 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 attribute.