public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@jifvik.org>
To: John Dallaway <john@dallaway.org.uk>
Cc: eCos development list <ecos-devel@ecos.sourceware.org>
Subject: Re: CDL usage and improvements
Date: Thu, 05 Apr 2012 20:26:00 -0000	[thread overview]
Message-ID: <4F7DFFC8.8010209@jifvik.org> (raw)
In-Reply-To: <4F7DEEDC.8070704@dallaway.org.uk>

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

  reply	other threads:[~2012-04-05 20:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05 19:14 John Dallaway
2012-04-05 20:26 ` Jonathan Larmour [this message]
2012-04-05 20:34   ` Jonathan Larmour
2012-04-15 19:10   ` John Dallaway
2012-04-16 15:26     ` Jonathan Larmour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7DFFC8.8010209@jifvik.org \
    --to=jifl@jifvik.org \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=john@dallaway.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).