Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000083Taste[All Projects] Generalpublic2011-01-12 10:482024-03-20 13:16
Reportermaxime 
Assigned Tohugues 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Summary0000083:

Option to pass command line parameters to user code

Description

Foresee an option to pass some command line parameters to the initialization function of the user code, based on a flag in the interface view.

Discussion from the old googlecode repo:

Can you provide an example of this improvement ? In particular, how it would be
used and what should be generated ?

Sure:

In the Interface view (AADL), we add a property e.g. "get_parameters=>true" to one
(or several) function(s).

When I see it, I add to the "init" function that buildsupport generates two
parameters: int argc, char **argv

I will also generate in the concurrency view the same "get_parameters=>true" for the
thread corresponding to the function of the interface view.

When you (Ocarina) see this parameter, you pass argc and argv to the init function
of the thread. Nothing else.

When the init function calls the "startup" function of the user code, user can then
decide what to do with the parameters.

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000227)
hugues (administrator)
2011-01-12 11:09

There is no need to pass any extra parameters to such function
- for Ada code, all you need is to play with Ada.Command_Line
- for C code, all you need in the main() function is to copy argc argv into some global constants (symbols) exported, then any C function can use it.

So impact on the whole toolchain can be absolutely limited to zero, only for C a modification to po_hi_main.c to populate the corresponding symbols

(0000233)
maxime (administrator)
2011-01-12 12:43

Ok - your solution is indeed simpler. However using Ada.Command_Line is not wise, since it is depending on using the Ada runtime.

Your second point should be the rule for both Ada and C runtimes : export a global constant that both Ada and C can see.

(0000234)
hugues (administrator)
2011-01-12 12:47

The Ada runtime can be used in both setups: either Ada or C OS, the only restriction is on tasking itself;
but of course we can have argc/argv also for Ada

for the records, a UK-based company involved in ASSERT used this trick to configure its SpaceWire fake driver for tsim ;)

(0000241)
maxime (administrator)
2011-01-12 13:11

So can we agree on the two following globals:

int __argc;
char *__argv[];

Julien, can you set it when the main is in C,
Jérôme can you :

1) set it when the main is in Ada (including Pragma Export for C)
2) give the Pragma import syntax to use when the main is in C to access it from an Ada function

Only for native platforms

(0000243)
user2
2011-01-12 13:21

Wait guys, I think we go in the wrong direction. Using the command-line parameters is a really bad idea. Why ? Because only native machines use that and embedded system does not. In addition, by using this, we rely on string and so, would introduce string-management function that are most of the time forbidden due to indeterminism and other reasons.

At this point, I am just wondering what are the real need for that and what is the rationale. Can you provide an example for such a feature ?

(0000244)
maxime (administrator)
2011-01-12 15:06

As I said, it is only for native applications, not embedded/real-time ones.

The objective is to allow a new range of applications that can receive configuration parameters, flags, etc, as it is typical for command-line applications. Given the ease of implementing such feature I think we should not restrain ourselves from getting it.

BTW, you are doing string parsing at runtime in the current implementation of the driver configuration - I have been fighting against you for a year about that, so the argument is not accepted :-)

(0002223)
maxime (administrator)
2014-11-27 13:40
edited on: 2016-01-27 13:39

Jerome: I looked at what you proposed but the main() is not defined in po_hi_main.c, it is generated in main.c by Ocarina, and it is defined like that:
__PO_HI_MAIN_TYPE __PO_HI_MAIN_NAME (void)

These macros are defined in po_hi_task.h:

#if defined(POSIX) || defined (XENO_POSIX)

#define __PO_HI_MAIN_NAME main
#define __PO_HI_MAIN_TYPE int
#define __PO_HI_MAIN_ARGS int argc , char *argv[] , char **arge

(And they are different for each platform)

There are two issues:
1) Why is the __PO_HI_MAIN_ARGS not generated in main.c?
2) We cannot generate the copy to a global variable unless we add another #if defined(POSIX)... in the generated main.c

(0003245)
maxime (administrator)
2018-02-16 17:15

Even if we don't implement the copy to a global variable in C, I think it would still be good to fix the bug reported:

main.c (generated by ocarina) contains:

__PO_HI_MAIN_TYPE __PO_HI_MAIN_NAME (void)

while it should contain (I think):

__PO_HI_MAIN_TYPE __PO_HI_MAIN_NAME (__PO_HI_MAIN_ARGS)
(0003780)
maxime (administrator)
2021-05-21 10:06

@Jerome : was this fixed?


- Issue History
Date Modified Username Field Change
2011-01-12 10:48 maxime New Issue
2011-01-12 11:09 hugues Note Added: 0000227
2011-01-12 12:43 maxime Note Added: 0000233
2011-01-12 12:47 hugues Note Added: 0000234
2011-01-12 13:11 maxime Note Added: 0000241
2011-01-12 13:21 user2 Note Added: 0000243
2011-01-12 15:06 maxime Note Added: 0000244
2014-11-27 13:40 maxime Note Added: 0002223
2016-01-27 13:39 ttsiodras Note Edited: 0002223 View Revisions
2018-02-16 17:15 maxime Note Added: 0003245
2018-02-16 17:15 maxime Assigned To

=> hugues

2018-02-16 17:15 maxime Status

new => feedback

2021-05-21 10:06 maxime Note Added: 0003780
2021-05-21 10:06 maxime Status

feedback => assigned

2024-03-20 13:16 maxime Status

assigned => closed

2024-03-20 13:16 maxime Resolution

open => won't fix



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker