On Thu, Nov 30, 2000 at 02:54:19PM -0700, Andreas Dilger wrote:
> Andrea writes:
> > On Thu, Nov 30, 2000 at 01:05:53PM -0700, Andreas Dilger wrote:
> > > the RAID and LVM make_request functions should be changed to do that
> > > instead (i.e. 0 on success, -ve on error, and maybe "1" if they do their
> > > own recursion to break the loop)?
> >
> > We preferred to let the lowlevel drivers to handle error themselfs to
> > simplify the interface. The lowlevel driver needs to call buffer_IO_error
> > before returning in case of error.
>
> Even if the lowlevel driver handles the error case, it would still
> make more sense to stick with the normal kernel practise of -ERROR,
> and 0 for success. Then, if in the future we can do something with the
> error codes, at least we don't have to change the interface yet again.
You shouldn't see the fact that a storage management driver returns 0 as an
error. It has a different semantic, it only means: "the make_request callback
completed the request, it wasn't a remap". That's all. As said the highlevel
layer doesn't know anything about errors anymore, it only need to know when the
request is completed.
Of course if there's an error during a remap you can't continue so you have to
say "this request is completed" and to tell this you currently have to return
0. But 0 from the point of view of the highlevel layer doesn't mean "error".
I'd suggest to take a third way that is to define only two retvals:
BLKDEV_IO_REQ_COMPLETED
BLKDEV_IO_REQ_REMAPPED
Then it doesn't matter anymore what number they're defined to.
generic_make_request simply keeps looping as far as it gets
BLKDEV_IO_REQ_REMAPPED as retval.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
