From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6739 invoked by alias); 5 Apr 2012 19:14:02 -0000 Received: (qmail 6681 invoked by uid 22791); 5 Apr 2012 19:14:01 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from tetra.codeconfidence.com (HELO tetra.codeconfidence.com) (94.229.66.225) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Apr 2012 19:13:36 +0000 Received: from cog.dallaway.org.uk (cpc1-cmbg10-0-0-cust34.5-4.cable.virginmedia.com [81.102.132.35]) by tetra.codeconfidence.com (Postfix) with ESMTP id 3B071171AA97; Thu, 5 Apr 2012 20:13:34 +0100 (BST) 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 q35JDWj4019288; Thu, 5 Apr 2012 20:13:33 +0100 Message-ID: <4F7DEEDC.8070704@dallaway.org.uk> Date: Thu, 05 Apr 2012 19:14:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.24 (X11/20111109) MIME-Version: 1.0 To: Jonathan Larmour , Bart Veer CC: eCos development list Subject: CDL usage and improvements 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/msg00002.txt.bz2 [ continuing the discussion on CDL issues from bug #1001550 ] Jonathan Larmour wrote: > John Dallaway wrote: > > > The "set_value" keyword in ecos.db was introduced as a quick hack for use > > within the Red Hat test farm and was never intended to be used elsewhere. > > set_value will provide a user_value for the specified CDL item which can > > therefore be inadvertently changed using the "restore defaults" action in > > configtool. I would really like to consider the use of "set_value" to be > > deprecated. It should always be possible to use a separate tiny CDL-only > > package to achieve the same effect. Are you OK with this? > > 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. 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. 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. 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. 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. Ilija Kocho wrote: > Why isn't this available in CDL? I always wanted some kind of soft "requires", > that will set/change default value but not hinder user override. My proposed > name was supposed to be "recommends" but "set_value" is perhaps better. Jonathan Larmour wrote: > It isn't available in CDL because, as Bart would tell you, he's never been > given time to develop it. Although Bart did take a sabbatical year and > host-side CDL and configuration improvements was something he was going to be > working on in that time, I think in practice he found it difficult to make good > progress on it. I'm afraid I don't know what the status is or what the plans > are at the moment - it may be nearly complete, or he may not be developing it > much at the moment. Bart, what improvements did you have in mind? I am sure that many in the eCos community will have an opinion on how CDL can be improved. Let's keep any discussion on improvements to infrastructure open to all on this list. John Dallaway eCos maintainer http://www.dallaway.org.uk/john