[patch/rfc] to_read/write_partial -> to_xfer_partial

[Andrew Cagney]

> On Oct 27,  3:25pm, Andrew Cagney wrote:
> 
> 
>> 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. 
  Compare target_read and target_write:

   LONGEST xfered = 0;
   while (xfered < len)
     {
       LONGEST xfer = target_read_partial (ops, object, annex,
                                           (bfd_byte *) buf + xfered,
                                           offset + xfered, len - xfered);
       /* Call an observer, notifying them of the xfer progress?  */
       if (xfer <= 0)
         /* Call memory_error?  */
         return -1;
       xfered += xfer;
       QUIT;
     }
   return len;

and

   LONGEST xfered = 0;
   while (xfered < len)
     {
       LONGEST xfer = target_write_partial (ops, object, annex,
                                            (bfd_byte *) buf + xfered,
                                            offset + xfered, len - xfered);
       /* Call an observer, notifying them of the xfer progress?  */
       if (xfer <= 0)
         /* Call memory_error?  */
         return -1;
       xfered += xfer;
       QUIT;
     }
   return len;

In testing this interface I had to fix similar but not identical bugs in 
both paths.

- If this were OO, I'd be doing it differently :-/

- unlike the memory xfer method, this one takes an explicit read and 
write buffer - the problem of casting away "const" is avoided.

- the core code doesn't need to be aware of this target internal detail, 
continuing to use more sane read/write methods.

enjoy,
Andrew