From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11382 invoked by alias); 19 Feb 2009 14:40:08 -0000 Received: (qmail 11374 invoked by uid 22791); 19 Feb 2009 14:40:07 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SARE_FWDLOOK X-Spam-Check-By: sourceware.org Received: from mtaout02-winn.ispmail.ntl.com (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Feb 2009 14:39:57 +0000 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090219143954.LIZO4080.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Thu, 19 Feb 2009 14:39:54 +0000 Received: from cog.dallaway.org.uk ([213.106.81.244]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090219143954.OOII21638.aamtaout02-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Thu, 19 Feb 2009 14:39:54 +0000 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id n1JEdpm6013244; Thu, 19 Feb 2009 14:39:52 GMT Message-ID: <499D6F37.7090902@dallaway.org.uk> Date: Thu, 19 Feb 2009 14:40:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 To: Bart Veer , Jonathan Larmour CC: ecos-maintainers@ecos.sourceware.org Subject: Re: Flash subsystem update References: <4992951D.10004@dallaway.org.uk> <499A12DD.4060609@eCosCentric.com> <499A849D.6030809@dallaway.org.uk> <499B33AE.6050608@dallaway.org.uk> <499CA2FD.2000504@eCosCentric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-02/txt/msg00037.txt.bz2 Hi Jifl and Bart Jonathan Larmour wrote: > ... 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. and Bart Veer replied: > Your change to cyg_flash_init() has broken API compatibility for every > flash-using application that has used the V2 flash branch since it was > created. It has also broken API compatibility for every application > that has used the V2 flash API since that was merged into the anoncvs > trunk. It has also broken API compatibility for every eCosPro release > for the last four years or so. So it seems you have opposite perspectives on whether it is preferable to: a) preserve API compatibility when the flash subsystem switches over to using a prioritized constructor, leaving legacy support code in place for the foreseeable future or b) break API compatibility now, drawing the attention of developers to the forthcoming change and providing a route to the complete elimination of deprecated code in the future There is no "right answer" here, but I would note that: * A major new release of the code is the best time to make forward-looking API changes * As things stand, breakage to existing application builds will be trivial to fix at the application level I suggest we give the other eCos maintainers an opportunity to comment today. I will defer branching for eCos 3.0 until tomorrow morning. John Dallaway eCos 3.0 release manager