public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: John Dallaway <john@dallaway.org.uk>
To: Jonathan Larmour <jifl@ecoscentric.com>,
	Bart Veer <bartv@ecoscentric.com>
Cc: ecos-maintainers@ecos.sourceware.org
Subject: Flash subsystem update [ was Re: eCos 3.0 beta 1 punch list #2 ]
Date: Tue, 17 Feb 2009 09:34:00 -0000	[thread overview]
Message-ID: <499A849D.6030809@dallaway.org.uk> (raw)
In-Reply-To: <499A12DD.4060609@eCosCentric.com>

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

  parent reply	other threads:[~2009-02-17  9:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11  9:07 eCos 3.0 beta 1 punch list #2 John Dallaway
2009-02-13 19:56 ` Bart Veer
2009-02-17  1:29   ` Jonathan Larmour
2009-02-17  9:18     ` Jonathan Larmour
2009-02-17  9:34     ` John Dallaway [this message]
2009-02-17 22:01       ` Flash subsystem update John Dallaway
2009-02-18 12:47         ` Bart Veer
2009-02-19  0:08           ` Jonathan Larmour
2009-02-19 11:50             ` Bart Veer
2009-02-19 14:40               ` John Dallaway
2009-02-19 15:13                 ` Bart Veer
2009-02-19 20:53                   ` Jonathan Larmour
2009-02-20  9:16                 ` John Dallaway
2009-02-19 20:31               ` Jonathan Larmour
2009-02-20 12:55                 ` Bart Veer
2009-02-20 21:22                   ` Jonathan Larmour
2009-02-17 21:07     ` eCos 3.0 beta 1 punch list #2 Bart Veer
2009-02-17 23:10       ` Jonathan Larmour
2009-02-19  0:48 ` Jonathan Larmour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=499A849D.6030809@dallaway.org.uk \
    --to=john@dallaway.org.uk \
    --cc=bartv@ecoscentric.com \
    --cc=ecos-maintainers@ecos.sourceware.org \
    --cc=jifl@ecoscentric.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).