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]

Flash subsystem update [ was Re: eCos 3.0 beta 1 punch list #2 ]

Hi Jifl and Bart

Regarding the prioritised constructor for Flash and consequent API
changes, Jonathan Larmour wrote:

> If the API is wrong we need to fix out before we make a major release. A
> stable flash API was the second most critical change to make for eCos
> 3.0 after the header updates. We can't flub it. This is a problem I
> raised with you back in 2006.
> Let me know what you consider the problems to be and I will deal with
> them.

and later wrote:

> More constructively, until I know what the "messy" bit is, I suggest
> adding:
> externC cyg_flash_printf *cyg_flash_set_printf( const cyg_flashaddr_t
> base, cyg_flash_printf *pf);
> which associates the printf function of flash at base 'base' with
> function 'pf', returning its previous setting. There would also be:
> #define CYG_FLASH_SET_PRINTF_ALL ((cyg_flashaddr_t)-1);
> which is used to set all devices' printf functions (and always return
> NULL).
> We can instantly deprecate use of cyg_flash_init with non-NULL argument.
> And if the messiness is too much to deal with after all, we can continue
> with cyg_flash_init, and in future it would be more or less #defined to
> cyg_flash_set_printf.

FAOD, I'll take this as a showstopper issue for 3.0 beta 1 on the basis
that we don't want API changes between beta and final. My concerns are:

a) Further slippage to the beta release.

b) The trunk is currently semi-frozen (no large/invasive changes) which
prevents the maintainers from undertaking regular maintainer duties.

The two issues are, of course, related. If we're able to address the
Flash issue this week, I think it makes sense to cut the 3.0 release
branch now (while we have stability) and double commit the Flash API
changes to address issue (b). If the Flash issue will take longer, then
we should hold back on cutting the branch and lift the semi-frozen
status of the repository. We then risk some de-stabilisation.

We need to contain further slippage as far as practically possible and
push forward with eCos 3.0. I would therefore like to ensure we have a
well-understood plan for addressing this issue in a realistic timescale.
Firstly, we need to understand the issues that Bart encountered in
detail. Bart, can you provide this detail today please? Does Jifl's
proposed workaround work for you?

John Dallaway

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