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

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" wrote:

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

Depends on what you mean by ``flag day''.

I can see the following ongoing process occuring:

	o	new interfaces being introduced
		(see gdbarch_register_{read,write})

	o	redundant interfaces (from above)
		being deprecated or deleted

	o	targets that are full of deprecated
		code being obsoleted.

The emphasis being on a continuum of change rather than single ``flag
days''.  That way, at any stage, GDB should still be working and
stable.  I could, in theory, cut a new GDB release at any time - the
project shouldn't be able to go down the rat hole of wildly osolating
between radical new development and stablizing for the next release.

However, I do see something very similar to a ``flag day'' looming.  A
line needs to be draw in the sand after which point any target (read x86
and arm) that isn't using gdbarch will be obsoleted.  

That line should probably be called ``5.2''.

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

I'm expecting to see the following process:

	o	a new interface being introduced

	o	where applicable legacy code
		for the previous interface being
		provided.

	o	that new interface evolve and
		stablize.

		This is important, it allows the
		new interface to stablize without
		the need to constantly change all
		the existing targets.

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

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

As an example, consider the gdbarch_register_{read,write} and associated
changes.  I wouldn't expect existing code to rush out and use this now. 
Rather, I'd expect people maintaining existing targets to wait a little
and then leap frog the current interface going straght to what is
hopefully the final version.

Any way, in the end it is a balancing act between keeping GDB stable and
allowing new development :-)

	Andrew