Re: Flash subsystem update

[Jonathan Larmour <jifl@eCosCentric.com>]

Bart Veer wrote:
> 
> By far the most sensible thing to do right now is to leave things
> exactly as they are. The functionality change is of interest to very
> few if any users. It may be interesting to us in the long term if we
> want to statically initialize more subsystems, but that does not
> require anything to be done today. There are no significant API
> compatibility implications: all of the functions that exist today will
> continue to exist; one of them will become pretty much irrelevant and
> users will be warned that they can safely remove it and save a few
> bytes, but it will continue to exist.

I still think you haven't got the point of what is being discussed. As 
I've mentioned a few times now, your concerns are to do with initialising 
by C++ constructor. While I think the risks of this change are rather 
theoretical, the effects on setting the printf function are not, and 
that's the source of API breakage when cyg_flash_init disappears in future.

Since you aren't keen to work on 3.0 any more or discuss further, 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.

The patch adds the functions proposed by your good self on 18th Nov and 
updates everything accordingly, including docs. See ecos-patches.

Jifl
-- 
*See us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300*
eCosCentric Limited      http://www.eCosCentric.com/     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