From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31571 invoked by alias); 5 Apr 2012 20:26:10 -0000 Received: (qmail 31542 invoked by uid 22791); 5 Apr 2012 20:26:07 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED 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; Thu, 05 Apr 2012 20:25:50 +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 q35KPk102372; Thu, 5 Apr 2012 21:25:46 +0100 (BST) Received: from shurg.barn.ecoscentric.com (unknown [87.127.120.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id D8E453FE1; Thu, 5 Apr 2012 21:25:45 +0100 (BST) Message-ID: <4F7DFFC8.8010209@jifvik.org> Date: Thu, 05 Apr 2012 20:26:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: John Dallaway Cc: eCos development list Subject: Re: CDL usage and improvements References: <4F7DEEDC.8070704@dallaway.org.uk> In-Reply-To: <4F7DEEDC.8070704@dallaway.org.uk> Content-Type: text/plain; charset=ISO-8859-1 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: 2012-04/txt/msg00003.txt.bz2 On 05/04/12 20:13, John Dallaway wrote: > Jonathan Larmour wrote: [Wanting to stop using set_value] >> Not really, no. Firstly, other targets use it. Secondly, the design intention >> for CDL is that targets should be defined by platform packages, albeit with >> "requires" rather than "set_value". As such this is much closer to the way >> things are intended to be. Yes it originated as a solution to a specific >> problem, but then so is ecos.db, which shouldn't exist at all. What we can do >> at the moment is make the transition to a future improved world easier, so that >> makes this approach better. > > Jifl, there are just four other instances of the use of set_value in > ecos.db at present and in every case the command is actually unnecessary > as it sets the user_value of a CDL option to the same value as the > default_value. Actually, you also need to equivalently consider the use "enable", which is pointlessly used by the snds, but usefully used by the adder / adderII. > Discouraging the use of what is known to be a problematic > command seems entirely reasonable to me. I think you may be > underestimating how useful the "Restore Defaults" command is to regular > configtool users. Certainly I would not regard this command 'obscure' by > any means. Okay, hands up any configtool users (not maintainers) out there who have used this command, AND it's done what they wanted. Also, given that the config tool has a long-standing problem of invoking the inference engine incorrectly, I would consider "restore defaults" to be a rather risky operation - the graphical config tool's inference engine has the potential to do something different once things set via templates are unwound. It would certainly be extremely noisy. I would have thought no-one would use "restore defaults", but instead just create a new configuration. That's more straightforward, more familiar and more likely to work. "Restore defaults" is probably a misnomer, because it isn't the defaults you get when you create a new configuration (although if you are lucky it may end up that way after inference / conflict resolution). > Given that the design intention is to use platform packages to define > targets, I don't understand why you would regard using a "set_value" > command (located outside the HAL package hierarchy) as being closer to > how things are supposed to be. Because the setting of options is associated with the target entry, which comes from the platform HAL package. > I am suggesting that we use additional > platform packages to set configuration options appropriate for specific > targets. This seems absolutely aligned with the design intention which > allows a combination of HAL packages to describe the hardware. I'm not saying it wouldn't work. But I'm against a pointless package cluttering up the target-side repository. It's not like this may result in some hidden subtle effect. If you configure for the wrong hardware the effect will be obvious and instantaneous - it won't work. > There is > a big difference between the use of "set_value" (an optional command) > and the use of ecos.db itself which, for better or for worse, is an > essential part of our infrastructure at present. > > If you remain unconvinced about deprecating "set_value", I suggest we > talk and then summarise to the list. No, keep it on the list for anyone interested, including other maintainers, to be involved; like as you say further down in your section to Bart. Incidentally, you have the wrong email address for Bart, he is no longer at eCosCentric. I will forward your mail just in case. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine