[Fwd: Re: feedback requested on proposed new directive]

[Charles-Antoine Gauthier]

Rosimildo da Silva wrote:
> 
> Joel Sherrill wrote:
> >
> >
> > Tradition.... Tradition... How did this tradition get started?
> > I'll tell you... I don't know.
> >
> > <apologies to Fiddler on the Roof :)>
> >
> > OK.. I'll bite. :)
> >
> > Every task is capable of using any API. But I understand your meaning...
> >
> > We probably should borrow an idea I worked out for GNAT/RTEMS.  There is
> > an RTEMS init task (API flavor is irrelevant).  It does whatever it
> > takes to initialize things before calling "Ada main".  What about
> > something like this?
> >
> > rtems_task Init()
> > {
> >   int status;
> >
> > #if defined(GET_ARGS)
> >   gets(cmdline);
> >   parse cmdline into argc, argv
> > #endif
> > #if defined(MOUNT_REAL_DISKS)
> >   initialize disk based filesystems
> > #endif
> > #if defined(HAS_NETWORKING)
> >   initialize networking
> > #endif
> >
> >   status = main( argc, argv, environp );
> >   exit( status );
> > }
> >
> > As time goes on, I can see other initialization that would have to be
> > inserted
> > before main() -- network initialization is already there.  Mounting
> > a real disk filesystem would be another.
> >
> > [I can easily see a way to instantiate this code via something like
> > confdefs.h.]
> 
> This sounds good. As long as the "init_task()" it is located alone
> in a module and let people be able to use its own, if needed.
> 
> >
> > Given the above scheme it would if USE_INIT_FINI were defined in bsp.h.
> >
> 
> Yes.
> 
> > One of the network demos (ttcp?) has code to convert a string into an
> > argc/argv
> > type arrangement.  Then the "ttcp_main" is invoked with them.  The
> > example above
> > I hacked would call that code.
> >
> 
> It is ok. But, getting the string from "stdin" would be a mistake if it
> is used
> by default. Just my opinion here.
> 

Sorry, I don't quite understand the paragraph above, but it sounds
important.

One of the obvious schemes for getting argv (and envp while we're at it)
is to compile it or the string to create it into the executable image.
It doesn't really matter whether argv is provided as an array of strings
or whether it is constructed from a single string, except that it is
probably easier to get a single string into the image, and then parse
it.

For automated testing, the general case is to invoke a single program
several times with different arguments Building separate images in this
case is not the best solution. Other solutions are:

1. Download the arguments as a string to a known location in the target
before starting execution, the parse the string into argv. Downloading
arguments to a known location can probably be done with a lot of boot
loaders. The Motorola xxxBug monitors typically can download both an
image and a argument file into RAM.

2. Read the string from stdin or from some other predetermined stream
before calling main. Somehow, this will require some means of
differentiating the case when no arguments are being supplied to the
image from the case where arguments are being supplied, otherwise the
init task might wait forever on stdin or might take the initial input as
the arguments to pass to main. The obvious solution is to have the
application specify whether it expects input before the main thread is
fired.

I just want to make sure that RTEMS has support for more than one
solution. In most real applications, I would probably use the
compiled-in default arguments, but for some automated regression tests,
I need to supply the command line separately from the executable image. 

> Rosimildo.

-- 
Charles-Antoine Gauthier
Institute for Information Technology   Institut de technologie de
l'information
National Research Council of Canada    Conseil national de recherches du
Canada