From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31571 invoked by alias); 19 Feb 2009 00:08:32 -0000 Received: (qmail 31560 invoked by uid 22791); 19 Feb 2009 00:08:31 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Feb 2009 00:08:25 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 681F53B40043; Thu, 19 Feb 2009 00:08:22 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27+wLTgxi1mb; Thu, 19 Feb 2009 00:08:21 +0000 (GMT) Message-ID: <499CA2FD.2000504@eCosCentric.com> Date: Thu, 19 Feb 2009 00:08:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515) MIME-Version: 1.0 To: Bart Veer CC: John Dallaway , 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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/msg00034.txt.bz2 Bart Veer wrote: > > By far the most sensible thing to do right now is to leave things > exactly as they are. The functionality change is of interest to very > few if any users. It may be interesting to us in the long term if we > want to statically initialize more subsystems, but that does not > require anything to be done today. There are no significant API > compatibility implications: all of the functions that exist today will > continue to exist; one of them will become pretty much irrelevant and > users will be warned that they can safely remove it and save a few > bytes, but it will continue to exist. I still think you haven't got the point of what is being discussed. As I've mentioned a few times now, your concerns are to do with initialising by C++ constructor. While I think the risks of this change are rather theoretical, the effects on setting the printf function are not, and that's the source of API breakage when cyg_flash_init disappears in future. Since you aren't keen to work on 3.0 any more or discuss further, 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. The patch adds the functions proposed by your good self on 18th Nov and updates everything accordingly, including docs. See ecos-patches. 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