From: Jonathan Larmour <jifl@eCosCentric.com>
To: Bart Veer <bartv@ecoscentric.com>
Cc: John Dallaway <john@dallaway.org.uk>,
ecos-maintainers@ecos.sourceware.org
Subject: Re: eCos 3.0 beta 1 punch list #2
Date: Tue, 17 Feb 2009 01:29:00 -0000 [thread overview]
Message-ID: <499A12DD.4060609@eCosCentric.com> (raw)
In-Reply-To: <pn3aeidsbu.fsf@delenn.bartv.net>
Bart Veer wrote:
> In theory there is one more change to go in: updating the flash
> subsystem to use a prioritized constructor, and associated API
> changes. Effectively this would replace explicit calls of
> cyg_flash_init() with automatic initialization via a C++ static
> constructor. That should simplify higher-level code since there is no
> longer any need to worry about whether or not the flash subsystem has
> been initialized. It would also give some code size savings in the
> flash subsystem, and in the medium to long term it would allow other
> subsystems such as fconfig to be statically initialized as well.
>
> However, after experimenting with various different patches, I have
> come to the conclusion that this is not the right time to make the
> change. It is not too bad when there is only a single flash device and
> everything works, but if there are initialization problems then things
> get messy.
I need more detail than "get messy". This is what the dev->init member is
meant to be for. Uninitialised devices get subsequently ignored, and the
return value of cyg_flash_init is irrelevant.
As with the spec for CYGBLD_GLOBAL_WARNINGS, you seem to be unilaterally
moving the goalposts from what had previously been agreed *extremely* late
in the day.
> So instead of making the change now, for all anoncvs
> targets and with no possiblity of testing on most of those targets, I
> want to do the work in eCosPro first. It can then be merged into a
> future anoncvs release, once I am confident that it is not going to
> break anything.
Why can it not be in both? Why should eCosPro be special with respect to a
changing API? And incompatible.
I don't know whether to wear an eCosCentric hat which says that eCosPro
should be aimed at well tested code, rather that a testbed for allegedly
unstable new code; or wear a maintainer hat and say that what happens in
eCosPro is not relevant to the public project, and API incompatibilities
made in such a way as to place eCosPro as "more advanced" is not a
principle to be encouraged.
> 2) the specification of cyg_flash_init(), i.e. whether or not it
> takes a printf() function as argument, is not actually important.
> cyg_flash_init() will become deprecated, and mostly a no-op, when
> the flash subsystem switches to using a prioritized constructor.
> It does not actually matter if a deprecated function takes a
> function pointer as argument.
But you've completely omitted how to properly set the printf function.
> That means there are no long-term API concerns either. There are
> functions to be added to the API, but those can wait till later.
I disagree. This means we are issuing an API which we have to instantly
deprecate and anyone presently coding to that API will encounter breakage
later.
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.
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
next prev parent reply other threads:[~2009-02-17 1:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-11 9:07 John Dallaway
2009-02-13 19:56 ` Bart Veer
2009-02-17 1:29 ` Jonathan Larmour [this message]
2009-02-17 9:18 ` Jonathan Larmour
2009-02-17 9:34 ` Flash subsystem update [ was Re: eCos 3.0 beta 1 punch list #2 ] John Dallaway
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=499A12DD.4060609@eCosCentric.com \
--to=jifl@ecoscentric.com \
--cc=bartv@ecoscentric.com \
--cc=ecos-maintainers@ecos.sourceware.org \
--cc=john@dallaway.org.uk \
/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).