This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Flash subsystem update

Bart Veer wrote:
    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.

Deprecating an API function means requiring API users to stop using it. Are you requiring them to change their application, freshly written to this new API, or not?

Until my change, the only way to set the printf function was with cyg_flash_init. That function rightly should go away, not bloat things in perpetuity.

Jifl's patches have broken API compatibility with existing code. In
future his modified cyg_flash_init() will still exist but it will be
deprecated in the same way as per my proposal.

So Jifl's patches have gained us absolutely nothing. However they have
broken compatibility for existing applications, and with 4+ years of
eCosPro releases.

Again, I'm writing solely as a maintainer.

I'd like to know how many applications you think are based on the *public* eCos project using flash v2, given its dependency on an ancient tree. I do know that people _tried_ to use it. And gave up.

I did think of retaining the existing function signature, but documenting a requirement for a NULL argument, but there seemed no point given this has never been a proper API. Moreover changing the function signature means that should there somehow be incorrect use of cyg_flash_init, it will result in a cleanly reported error to the user. Not that I expect that to happen outside of eCosCentric (RBL is the only thing I can think of).

The only people affected are eCosCentric, because they/we slightly jumped the gun and integrated it in their own trunk rather than making that effort in the public sources. With a maintainer's hat on, that's not to do with the public project.

*See us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300*
eCosCentric Limited     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]