Re: [PATCH] readX_relaxed interface
From: Hironobu Ishii (ishii.hironobu_at_jp.fujitsu.com)
Date: 01/19/04
- Previous message: Yumiko Sugita: "LKST v2.0.1 for Kernel 2.6.0 is released."
- In reply to: Grant Grundler: "Re: [PATCH] readX_relaxed interface"
- Next in thread: Grant Grundler: "Re: [PATCH] readX_relaxed interface"
- Reply: Grant Grundler: "Re: [PATCH] readX_relaxed interface"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 19 Jan 2004 18:31:42 +0900 To: Grant Grundler <iod00d@hp.com>, Greg KH <greg@kroah.com>
----- Original Message -----
From: "Grant Grundler" <iod00d@hp.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.
I've also worked on such system.
I understand it's difficult all drivers use that kind of an interface.
But if some common drivers like scsi, FC and LAN drivers use such interface,
it's usefull for most users.
>
> > 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).
But, when the read thread continues without noticing the error
(before the error is asynchronously notified),
the thread runs based on wrong data and may panic.
So I think PIO read error must be notified synchronously.
On the other hand, PIO write error can be notified asynchronously,
because software does not use it.
Hironobu Ishii
-
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/
- Previous message: Yumiko Sugita: "LKST v2.0.1 for Kernel 2.6.0 is released."
- In reply to: Grant Grundler: "Re: [PATCH] readX_relaxed interface"
- Next in thread: Grant Grundler: "Re: [PATCH] readX_relaxed interface"
- Reply: Grant Grundler: "Re: [PATCH] readX_relaxed interface"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
