public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
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: Flash subsystem update
Date: Thu, 19 Feb 2009 20:53:00 -0000	[thread overview]
Message-ID: <499DC6A8.5010900@eCosCentric.com> (raw)
In-Reply-To: <pnhc2qjw99.fsf@delenn.bartv.net>

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.

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

  reply	other threads:[~2009-02-19 20:53 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     ` 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 [this message]
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=499DC6A8.5010900@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).