From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15556 invoked by alias); 16 Oct 2009 01:45:38 -0000 Received: (qmail 15545 invoked by uid 22791); 16 Oct 2009 01:45:37 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Oct 2009 01:45:31 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id n9G1jT422165; Fri, 16 Oct 2009 02:45:29 +0100 (BST) Received: from [172.31.1.126] (neelix.jifvik.org [172.31.1.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 8439B3FEB; Fri, 16 Oct 2009 02:45:28 +0100 (BST) Message-ID: <4AD7D036.1090606@jifvik.org> Date: Fri, 16 Oct 2009 01:45:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: Rutger Hofman Cc: 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> <4AD73810.5040608@cs.vu.nl> In-Reply-To: <4AD73810.5040608@cs.vu.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00028.txt.bz2 Rutger Hofman wrote: > > 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. I think that's the way to do it - asserts for programming errors (things which should never ever happen), and errors for things which could maybe happen in the field, e.g. due to hardware errors. If you prefer you could change the existing printfs into some sorts of macros which you'd only want to see if you're debugging NAND operation, and completely left out otherwise. Like CYG_NAND_CHATTER. Or perhaps some of them should be turned into CYG_NAND_CHATTER, it depends. > 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. If the decision is made to adopt your one, that's a change I think would be beneficial yes, and can be done then. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine