John> So it seems you have opposite perspectives on whether it is
John> preferable to:
John> a) preserve API compatibility when the flash subsystem
John> switches over to using a prioritized constructor, leaving
John> legacy support code in place for the foreseeable future
John> or
John> b) break API compatibility now, drawing the attention of
John> developers to the forthcoming change and providing a route
John> to the complete elimination of deprecated code in the future
John> There is no "right answer" here, but I would note that:
John> * A major new release of the code is the best time to make
John> forward-looking API changes
John> * As things stand, breakage to existing application builds will be
John> trivial to fix at the application level
John> I suggest we give the other eCos maintainers an opportunity
John> to comment today. I will defer branching for eCos 3.0 until
John> tomorrow morning.
No, you still don't understand. My original proposal NEVER breaks
compatibility. Not now, because it involved zero changes to the API.
Not in future, because there will always be a cyg_flash_init() with
the exact same interface as it does now. It will become deprecated but
it will still exist.