lkml.org 
[lkml]   [2014]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 10/13] eeepc-laptop: compare proper return values in get_cpufv
    On Wed, Sep 17, 2014 at 01:57:33PM +0200, Frans Klaver wrote:
    > On Wed, Sep 17, 2014 at 12:34 PM, Henrique de Moraes Holschuh
    > <hmh@hmh.eng.br> wrote:
    > > On Tue, 16 Sep 2014, 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
    > >
    > > from errno(3):
    > > EIO Input/output error (POSIX.1)
    > > ENXIO No such device or address (POSIX.1)
    > >
    > > It makes sense to retry EIO. ENXIO means there's nobody listening at the
    > > time, and isn't usually retried.
    > >
    > > The device-based interfaces get it right. A typical example is the
    > > cpu-based devices, where ENXIO means "no such processor", while EIO means
    > > "whatever you're trying to do failed", so a MSR read would return ENXIO if
    > > the processor core is offline/doesn't exist, and EIO if the processor core
    > > is there, but raised a #GP when the MSR read was attempted.
    >
    > Here's something I don't quite understand. How should one then
    > distinguish between sysfs's use of EIO "can't (read from|write to)
    > this file", and this example's EIO "something went wrong, you might
    > want to try again"? Why not use EAGAIN "Resource temporarily
    > unavailable" in the case where trying again makes sense? I wouldn't
    > normally retry the last operation if I was just told something
    > actually went wrong.
    >
    > I've only been at it for a couple of weeks, but I get the impression
    > that sysfs has never really been guided regarding error codes, or has
    > gone to live its own life now kept in check with "don't change the
    > errors, it may break userspace". Does that make sense?

    Right, this was the distinction I was trying to make with the above description.
    Henrique's points are valid, but based on the sysfs subsystem already using EIO
    in the way that it does, I felt the above made sense.

    That said, I'm not personally tied to them, it's just what I have derived from
    recent discussions on the subject and what I observed in existing usage.

    --
    Darren Hart
    Intel Open Source Technology Center


    \
     
     \ /
      Last update: 2014-09-17 18:41    [W:3.007 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site