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

[Andrew Cagney <ac131313@redhat.com>]

> 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.

Andrew