Re: [PATCH] readX_relaxed interface

From: Grant Grundler (iod00d_at_hp.com)
Date: 01/16/04

  • Next message: Mike Fedyk: "Fwd: [2.6] nfs_rename: target $file busy, d_count=2" 
    Date:	Thu, 15 Jan 2004 21:00:59 -0800
To: Greg KH <greg@kroah.com>

    On Thu, Jan 15, 2004 at 04:32:25PM -0800, Greg KH wrote:
    > It looks ok, but it would really be good if we could indicate if the
    > read actually was successful. Right now some platforms can detect
    > faults and do not have a way to get that error back to the driver in a
    > sane manner. If we were to change the read* functions to look something
    > like:
    > int readb(void *addr, u8 *data);
    > it would be a world easier.

    I've worked on systems with that kind of an interface and it
    really makes a mess of the code. And many of the drivers just
    ignored the read return value.

    > Now I'm not saying I want to change the existing interfaces to support
    > this, that's too much code to change for even me (and is a 2.7 thing.)

    I think you'll find it's extremely invasive if it's going to be useful.
    The drivers have to be rewritten to check each PIO return value
    and then do something intelligent at that point. HPUX had drivers
    that did this for "Host Power Fail" support 10 years ago but
    it's *very* difficult to get all the error handling right in
    each of the code pathes.

    My preference is the driver register a "clean up all pending IO and
    free related data structures" so it's back to a state as if it hadn't
    been started. Then when a PIO read (or write) fails, the mechanism for
    detecting the read failure doesn't depend on synchronous errors being
    reported/checked by software on each read. ie the mechanism for
    detecting the failure *can* be in the PIO read code path but
    doesn't have to be if HW has facilities to detect failures.
    (I'm thinking of parisc HPMC and ia64 MCA handling).

    > Just wanted to put this idea in people's heads that we need to start
    > planning for something like it.

    yeah - getting to the next level of availability on higher end systems
    is hard. I'm not totally convinced it's the right thing for linux
    to do, but if someone wants to fund the work, it'll be interesting
    to work on.

    grant
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Mike Fedyk: "Fwd: [2.6] nfs_rename: target $file busy, d_count=2"

    Relevant Pages