This is the mail archive of the
ecos-maintainers@sourceware.org
mailing list for the eCos project.
Re: Flash subsystem update
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