Command line arguments

[Ed Sutter]

> >On Thu, Oct 14, 2004 at 07:30:26AM -0400, Ed Sutter wrote:
> >> Lars,
> >> I beleive this is boot loader specific.  At the time of command
> >> line entry, the boot loader is still the active program, so it
> >> must provide the ability to deal with arguments.  In MicroMonitor,
> >> this is very easy to do and pretty much independent of the CPU/RTOS.
> >>
> >> Command line arguments established when the application starts up
> >> are stored in the monitor's environment, then through a monitor
> >> API call, they can be retrieved from anywhere in application
> >> space (assuming the application doesn't disallow access to the
> >> monitor's API because of MMU-based protection).
> >>
> >> In most uMon-based applications, this API call is made prior to main()
> >> so that argc/argv are populated just like a normal program; however,
> >> this isn't a requirement.
> >
> >Yes, I know of the monConnect and mon_getargv calls to uMon, but my
> >problem is not getting the arguments from the boot loader. My problem is
> >to get the arguments from the bootcard function into my task.
> >
> >Thanks
> >Lars Munch
> 
> We are using uMon, but ran into the same problem.  We retrieved the command
> line arguments in rtems_main, but didn't have a clean way to get them into the
> thread that needed them.  We probably could have waited to retrieve them from
> uMon until we were in that thread, but we used a couple of global variables instead.
> Some of the relevant code follows.  Please let me know if you need more information
> about what we did, or if you have a cleaner way of doing it.
> 


Steve,
I guess I'm confused with what the problem is.
You can call mon_getargv(&argc,&argv) from anywhere, and, if you have monlock
active (to protect against reentry), then you can call it multiple times.
Each task that needs some portion of the arg list can call it and populate it's
own private argument list, then just use the portion of the list it needs.
Does this make sense and/or help?
Ed