TASTE bugtrack - Taste
View Issue Details
0000083Taste[All Projects] Generalpublic2011-01-12 10:482024-03-20 13:16
maxime 
hugues 
normalfeatureN/A
closedwon't fix 
0000083: Option to pass command line parameters to user code
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.
No tags attached.
Issue History
2011-01-12 10:48maximeNew Issue
2011-01-12 11:09huguesNote Added: 0000227
2011-01-12 12:43maximeNote Added: 0000233
2011-01-12 12:47huguesNote Added: 0000234
2011-01-12 13:11maximeNote Added: 0000241
2011-01-12 13:21user2Note Added: 0000243
2011-01-12 15:06maximeNote Added: 0000244
2014-11-27 13:40maximeNote Added: 0002223
2016-01-27 13:39ttsiodrasNote Edited: 0002223View Revisions
2018-02-16 17:15maximeNote Added: 0003245
2018-02-16 17:15maximeAssigned To => hugues
2018-02-16 17:15maximeStatusnew => feedback
2021-05-21 10:06maximeNote Added: 0003780
2021-05-21 10:06maximeStatusfeedback => assigned
2024-03-20 13:16maximeStatusassigned => closed
2024-03-20 13:16maximeResolutionopen => won't fix

Notes
(0000227)
hugues   
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   
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   
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   
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   
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   
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   
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   
2021-05-21 10:06   
@Jerome : was this fixed?