headers
John Dallaway | 5 Apr 2012 21:13
Picon

CDL usage and improvements

[ 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.
(Continue reading)

Permalink | Reply |
headers
Jonathan Larmour | 5 Apr 2012 22:25

Re: CDL usage and improvements

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
(Continue reading)

Permalink | Reply |
headers
Jonathan Larmour | 5 Apr 2012 22:33

Re: CDL usage and improvements

On 05/04/12 21:25, Jonathan Larmour wrote:
> On 05/04/12 20:13, John Dallaway wrote:
>> 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.

To be clear, I mean which _will_ come from the platform HAL package.

One thing the design did not include was extra little HAL packages whose
only raison d'être is to set a config option.

Jifl
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Permalink | Reply |
headers
John Dallaway | 15 Apr 2012 21:10
Picon

Re: CDL usage and improvements

Hi Jifl

Jonathan Larmour wrote:

> 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.

I agree. So prior to your check-in we had 4 unnecessary instances of
"set_value", 3 instances of "enable" (of which 1 was unnecessary) and no
instances of "disable".
(Continue reading)

Permalink | Reply |
headers
Jonathan Larmour | 16 Apr 2012 17:25

Re: CDL usage and improvements

On 15/04/12 20:10, John Dallaway wrote:
> 
>>> 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.
> 
> No responses to date, but I think you would agree that this polling
> technique is not the most objective. :-)

Well, it would only have taken one to put me in my place ;-).

>> 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).
> 
> In fact, "Restore Defaults" is much more useful when invoked at the CDL
> package or CDL component level rather than across the entire eCos
> configuration. Creating a new configuration is no substitute in these
(Continue reading)

Permalink | Reply |

Gmane