Re: [PATCH] readX_relaxed interface

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

  • Next message: Mike Fedyk: "Re: page allocation failure"
    Date:	Mon, 19 Jan 2004 10:18:08 -0800
    To: Hironobu Ishii <ishii.hironobu@jp.fujitsu.com>
    
    

    On Mon, Jan 19, 2004 at 06:31:42PM +0900, Hironobu Ishii wrote:
    > But, when the read thread continues without noticing the error
    > (before the error is asynchronously notified),

    I wasn't suggesting asynchonous notification.

    > the thread runs based on wrong data and may panic.

    So far I've been assuming resources/IO requests can be cleaned up
    more easily in a shared code path. I was assuming the readb() would
    call the "cleanup" and then return a "harmless" value (eg. 0 or -1)
    that was provided by the driver before hand. I'm more worried
    about the code that evaluates the readb() return value than
    synchronous notification or cleaning up resources.

    Having unique error recovery code after each PIO read did work
    but it was not an elegant solution. It was a problem of too much
    "unused" code interferring with the regular code path. And it
    didn't distinguish sufficiently between code to handle "platform"
    errors (failure to talk to a card) vs card errors (card
    failed an IO).

    I guess I'd need to modify one driver using my proposal
    instead of assuming it doesn't matter wether the recovery code
    lives immediately after the PIO read or in some common routine.
    Problem is I have other issues to deal with right now
    even though I've made clear to my management "HW error recovery"
    is required for higher levels of availability with linux.

    > So I think PIO read error must be notified synchronously.

    I agree.

    > On the other hand, PIO write error can be notified asynchronously,
    > because software does not use it.

    yes.

    thanks,
    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: "Re: page allocation failure"