Re: Flash subsystem update

[John Dallaway <john@dallaway.org.uk>]

Hi Jifl and Bart

Jonathan Larmour wrote:

> ... I'm checking in a patch which updates cyg_flash_init to remove
> its argument (I toyed with keeping the argument and deprecating it
> but that seemed the worst of all worlds by hiding the change for any
> existing API users). And the main benefit of doing so is that later
> on we can do:
> #define cyg_flash_init() CYG_EMPTY_STATEMENT
> and there's no overhead, and no API breakage.

and Bart Veer replied:

> Your change to cyg_flash_init() has broken API compatibility for every
> flash-using application that has used the V2 flash branch since it was
> created. It has also broken API compatibility for every application
> that has used the V2 flash API since that was merged into the anoncvs
> trunk. It has also broken API compatibility for every eCosPro release
> for the last four years or so.

So it seems you have opposite perspectives on whether it is preferable to:

a) preserve API compatibility when the flash subsystem switches over to
using a prioritized constructor, leaving legacy support code in place
for the foreseeable future

or

b) break API compatibility now, drawing the attention of developers to
the forthcoming change and providing a route to the complete elimination
of deprecated code in the future

There is no "right answer" here, but I would note that:

* A major new release of the code is the best time to make
forward-looking API changes

* As things stand, breakage to existing application builds will be
trivial to fix at the application level

I suggest we give the other eCos maintainers an opportunity to comment
today. I will defer branching for eCos 3.0 until tomorrow morning.

John Dallaway
eCos 3.0 release manager