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

[Kevin Buettner <kevinb at redhat dot com>]

On Oct 27, 11:26am, Andrew Cagney wrote:
> Subject: Re: [patch/rfc] to_read/write_partial -> to_xfer_partial

> >> Per: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00641.html
> > 
> >> > Having taken the change to this point, I'm now wondering if the read/write partial methods should be merged into:
> >> > to_xfer_partial (targ, object, annex,
> >> > offset, len,
> >> > readbuf, writebuf)
> >> > as that would make migrating existing targets easier.
> > 
> >> Having implemented bfd-target and remote-target versions 
> >> to_read/write_partial, I think this switch is going to make life easier. 
> > 
> > Could you offer a few more details on why you think that merging the
> > read/write methods into a single xfer method will make it easier to
> > migrate existing targets?
> 
> 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.

Kevin