Re: xfer_memory(..., attrib, ...) post mortem

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> It should be possible to modify the target vector without
Andrew> having to grep/examine every line of source and potentially
Andrew> breaking every target.
Andrew>
Andrew> With that in mind, I'd like to draw on the experience of
Andrew> gdbarch.{sh,h.c} and propose that the target vector be redone
Andrew> so that it is more along the lines of ``struct gdbarch *''.
Andrew>
Andrew> Doing that should make it possible for people to pull the now
Andrew> pretty standard hack of, instead of changing an existing
Andrew> interface, introduce a new one and rename the old to
Andrew> deprecated_*. A legacy function could be used to maintain
Andrew> compatibility.
Andrew
Andrew> Comments, [...] 

I want to point out that it is possible to take backwards
compatibility too far.  Experience has told me that when you have
a "flag day" conversion, there is a little pain as loose ends are
cleaned up, but then it's over and down with.  But if backwards
compatible interfaces are maintained, chances are good that nothing
will be done.  There is no incentive for change.  In the end, the
system is saddled with the complexity of multiple implementations.

That's why I approve (in principle) of the discussion to remove the
sync event loop even though it will likely break my remote-wdb.c back
end.

If anything, I think that we haven't been aggressive enough wrt.
flushing these from GDB.  e.g. changing FRAME_FIND_SAVED_REGS to
FRAME_INIT_SAVED_REGS is a reasonably easy change, but many ports
have yet to make the switch.

In short, I have no problems with global changes with unforseen rough
edges that get cleaned up in a few days for actively maintained
targets, and perhaps a bit longer for those targets that aren't.
I believe this results in better code in the long term, and the
occasional pain isn't great enough to outweigh this.

        --jtc

-- 
J.T. Conklin
RedBack Networks