From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29494 invoked by alias); 15 Oct 2009 14:55:29 -0000 Received: (qmail 29480 invoked by uid 22791); 15 Oct 2009 14:55:28 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from top.few.vu.nl (HELO top.few.vu.nl) (130.37.20.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 14:55:21 +0000 Received: from [130.37.30.42] (hppc190.cs.vu.nl [130.37.30.42]) by top.few.vu.nl with esmtp (Smail #115) id m1MyRjb-0000BoC; Thu, 15 Oct 2009 16:55 +0200 Message-ID: <4AD73810.5040608@cs.vu.nl> Date: Thu, 15 Oct 2009 14:55:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jonathan Larmour CC: =?ISO-8859-1?Q?J=FCrgen_Lambrecht?= , Ross Younger , eCos developers , Deroo Stijn Subject: Re: NAND technical review References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> <4AD3E92E.5020301@jifvik.org> <4AD47ADE.9010606@cs.vu.nl> <4AD6A7EC.8080703@jifvik.org> In-Reply-To: <4AD6A7EC.8080703@jifvik.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00025.txt.bz2 Jonathan Larmour wrote: > Rutger Hofman wrote: >> Jonathan Larmour wrote: > On a separate point, while I'm here, I think the use of printf via > cyg_nand_global.pf would want tidied up a lot. Some of them seem to be > there to mention errors to the user, but without any programmatic > treatment of the errors, primarily reporting them to higher layers. > > It should also be possible to eliminate the overheads of the printf. > Right now there's quite a lot of them, involving function calls, > allocation of const string data, and occasionally calculation of > arguments, even if the pf function pointer is pointing to an empty null > printf function. It should be possible to turn them off entirely, and > not be any worse off for it (including error reporting back up to higher > layers). It might not be so bad if the strings were a lot shorter, or > the printf functions less frequently used, but being able to turn them > off entirely would seem better. I agree. Many of the printfs are leftovers from debugging stages. They should go (and will go anyway at a next code cleanup), and an error should be reported upwards where that isn't done yet; or possibly asserts when they flag a programming error in this layer -- preferences? I will do this somewhere in the coming weeks. When the dependency on a memory allocator is also gone (see other response), there is no practical obstacle left to switch from explicit initialisation to init-time constructor. If this makes a difference in acceptance, I will convert from malloc and explicit initialisation somewhere within one month. Rutger