This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]