Re: [patch/rfc] to_read/write_partial -> to_xfer_partial

[Kevin Buettner <kevinb@redhat.com>]

On Oct 27,  7:02pm, Andrew Cagney wrote:

> > There's a tradeoff.  You'll notice that I started out with separate 
> >> asthetically pleasing read/write methods, but eventually decided the 
> >> cost was too high.
> >> 
> >> - the existing targets implement a memory centric "xfer".  Its going to 
> >> be easier [for me] to convert that code to this new xfer variant.
> >> 
> >> - both the read and write paths use identical buffer overflow logic, and 
> >> its that logic which contains the nasty edge cases and consequent bugs. 
> > 
> > 
> > Is there any reason you can't keep the methods separate, but use a
> > common underlying "xfer" implementation?  (Which, I think, is how
> > it's presently done.)  In the past, when trying to figure out how an
> > xfer implementation worked, I recall looking at how the read/write
> > stubs called the xfer function.
> 
> Sorry, I'm lost.
> 
> How is which presently done?  The patch retains the existing target 
> read/write partial interfaces but uses an underlying to_xfer_partial 
> vector method.  This is how the existing to_xfer_memory is implemented.

My recollection of how the code was structured was faulty.  I withdraw
my objections.

Kevin