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

[jtc@redback.com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Depends on what you mean by ``flag day''.
Andrew>
Andrew> I can see the following ongoing process occuring:
Andrew>
Andrew> 	o	new interfaces being introduced
Andrew> 		(see gdbarch_register_{read,write})
Andrew>
Andrew> 	o	redundant interfaces (from above)
Andrew> 		being deprecated or deleted
Andrew>
Andrew> 	o	targets that are full of deprecated
Andrew> 		code being obsoleted.
Andrew>
Andrew> The emphasis being on a continuum of change rather than single ``flag
Andrew> days''.  That way, at any stage, GDB should still be working and
Andrew> stable.  I could, in theory, cut a new GDB release at any time - the
Andrew> project shouldn't be able to go down the rat hole of wildly osolating
Andrew> between radical new development and stablizing for the next release.

I can't argue with anything you've said.  Whether it will work or not
depends on our committent to execute the above plan.  I have no doubts
about the first step, it's the second two that give me pause.  If the
backwards compatible infrastructure "works" well enough, there is no
incentive to complete the process.  When it comes to the decision to
obsolete an target because no one has bothered to update to the new
interfaces, we can't be swayed by the argument that we can't do that
because the target is important.  IMO if it was really important, it 
would have been kept up to date.

Andrew> 	o	the old/redundant interfaces be
Andrew> 		deprecated and/or that code be updated

Andrew> 		This is probably where GDB has
Andrew> 		been falling down.  I intend
Andrew> 		being really agressive with
Andrew> 		applying the mechanical operation
Andrew> 		s/interface/deprecated_interface/.

Good to hear.  I approve.

        --jtc

-- 
J.T. Conklin
RedBack Networks