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

True, although that could cause even further unintended consequences when
values in other packages had previously received inferred values from the
package where "restore defaults" is applied. It's a subtly dangerous
operation.

>> I'm not saying it wouldn't work. But I'm against a pointless package
>> cluttering up the target-side repository.
> 
> I don't think that using separate CDL packages to provide common and
> board-specific parts of a platform HAL is so very different from the
> partitioning of the HAL across multiple packages to accommodate
> processor variants, or other functional blocks with some common
> features.

It is a bit, given that people expect to find platform related options in
the platform HAL, and now there would be a sort-of platform variant HAL
stuck in the middle which is where the real meat is. It's something that
I've never been very happy about with the AT91SAM7S HAL, although it's
unavoidable there really as there is genuine board specific code there,
albeit very little. That would not apply here - AFAICT the board is
exactly the same (silk-screened "STM32 20-21-45-46 G-EVAL") but with a
different CPU fitted.

> One of the great benefits of CDL is that it provides the
> flexibility to accommodate abstractions that were not necessarily
> envisaged at design-time.

While that's true, the concept of target templates being able to set
values was something that /was/ envisaged at design time.

> Jifl, it seems that both our views are quite firm. Since you have
> already checked-in the new code and it is unlikely to impact too many
> people, I am not inclined to argue this further. However, I would still
> recommend that eCos developers avoid use of the "set_value", "enable"
> and "disable" commands in ecos.db where possible.

If anyone else wants to contribute to this (especially Bart of course) and
say that your greater good is more important than my greater good, then
fair enough, I'll go along with an outsider's view.

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]