headers
Lambrecht Jürgen | 4 Apr 2012 14:57
Favicon

Re: eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]

On 03/18/2012 08:09 PM, Ilija Kocho wrote:
>
> Hi Alex
>
> Thank you for testing 4.6.2-20120125.
>
> 4.6.3-20120315 is our new test release until we upgrade GDB with Jifl's
> patch:
> http://ecos.sourceware.org/ml/ecos-discuss/2012-03/msg00064.html
>
> Ilija
>
>
Hi all,

I finished building our "Passenger Information System" application with 
gcc 4.6.3 (started with 4.6.2, noticed no difference when switching to 
4.6.3).
Before, we used gcc 3.2.1.

I first built ecos v3.0 without any problem.
Then I built our application, and it took me many days to solve all new 
warnings (we compile with -Werror):
- unused-but-set-variable -> gave me problems with MISRA rule /16.10/ 
(If a function returns error information, then that error information 
shall be tested.) Our PC-lint checker forces any return argument to be 
used, so I had to add __attribute__ ((unused)).
Also, this warning is annoying for HW drivers: then you sometimes need 
to read some bit just to trigger some behavior, but you are not 
interested in the return value..
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ilija Kocho | 4 Apr 2012 15:18
Picon

Re: eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]

Hi Lambrecht

Many thanks for your report. This is AFAIK first report for ARM9.

There are warnings indeed. Many have been fixed in current CVS. Can you
please report warnings (and possibly propose) fixes in Bugzilla?

Thanks again
Ilija

On 04.04.2012 14:57, Lambrecht Jürgen wrote:
> On 03/18/2012 08:09 PM, Ilija Kocho wrote:
>> Hi Alex
>>
>> Thank you for testing 4.6.2-20120125.
>>
>> 4.6.3-20120315 is our new test release until we upgrade GDB with Jifl's
>> patch:
>> http://ecos.sourceware.org/ml/ecos-discuss/2012-03/msg00064.html
>>
>> Ilija
>>
>>
> Hi all,
>
> I finished building our "Passenger Information System" application with 
> gcc 4.6.3 (started with 4.6.2, noticed no difference when switching to 
> 4.6.3).
> Before, we used gcc 3.2.1.
>
(Continue reading)

Permalink | Reply | 1 comment |
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 | 4 comments |
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 | 3 comments |
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 | 0 comments |
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 | 1 comment |
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 | 0 comments |

Gmane