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

[Charles-Antoine Gauthier]

Rosimildo da Silva wrote:
> 
> From: Joel Sherrill <joel.sherrill at OARcorp.com>
> To: Rosimildo da Silva <rdasilva at connecttel.com>
> Cc: rtems <rtems-users at oarcorp.com>
> Sent: Monday, August 28, 2000 12:56 PM
> Subject: Re: [Fwd: Re: feedback requested on proposed new directive]
> 
> > Rosimildo da Silva wrote:
> >
> > > > We are considering adding a new directive to expose functionality
> > > > that has long been in the SuperCore.  It is an alternate task
> > > > entry style that follows "main".  Your task's argument list would
> > > > look like:
> > > >
> > > > rtems_task MYTASK( int argc, char ** argv )
> > >
> > > Why not a signature to match main():
> > >
> > >         int MYTASK( int argc, char ** argv );
> >
> > This is OK by me... but what to do when MYTASK returns?
> 
> Never mind. I thought this API was to start main(), but now I understand,
> it is just a call to be used inside the current main() routine.
> 
> >
> > > > The directive would look something like this (naming suggestions
> > > > requested :).
> > > >
> > > > rtems_status_code rtems_task_start_main_style(
> > > >   rtems_id         id,
> > > >   rtems_task_entry entry_point,  /* probably need another type? */
> > > >   int               argc
> > > >   char            **argv
> > > > );
> > >
> > > I guess the idea is to start main() routine from it ?
> > >
> > > Are you planning to remove the call to main() from boot_card.c ?
> >
> > Eventually I would like to do so.  It is impossible to support
> > all the weird things that a global constructor can do when running
> > in a state where you can't block.  This means you can't do IO in
> > many (most?) situations?
> >
> 

Yes yes yes! Do get rid of main in the startup code.

> Why not call main() from within the init_task ?
> Global Ctor would be called from inside this init task.

But this is a change in semantics. It requires that there be only one
init task for all APIs In fact, it removes the need for applications to
supply init tasks, unless the application supplied init tasks are just
created automatically by the new RTEMS-supplied init task, the one you
call init_task.

Was this discussed? Did I miss some threads?

> 
> start  ---> boot_card() ----> start multi-task --> init_task()  -->
> init()/fini()
> 

I am wondering if we need to register the exception tables earlier that
this? In which case, we must re-implement to functionality of _init to
call the __register_frame_info earlier, and call __do_global_ctors once
multitasking has started up.

If you don't call __register_frame_info early, then no user supplied
initialization code should throw an exception. This may not be a
significant limitation, but it should be documented.

> main()   --> user code.
> 
> > >  rtems_status_code rc;
> > >  rc = rtems_task_start_main_style( id, main, argc, argv );
> > >
> > > What happens when exit() &/or assert() are called ?
> >
> > Same thing that happens now.  The whole application gets shutdown.
> > We can discuss the semantics of what happens and modify them
> > over time.  Modifying the view of what happens will probably
> > be necessary as dynamic loading becomes real.
> >
> 
> Ok.
> 
> > > I guess it is important to know what we are trying to
> > > archive here:
> > >
> > >    + have a stardard way of starting up RTEMS.
> > >
> > >    + making easier porting 3rd party applications
> >
> > This is the initial and sole goal of the above.
> >
> > >    + providing a standard configuration
> > >
> > > All programmers expects something similar a "C" program
> > > as an entry point for any application.
> > > A RTEMS newbee would like to have this fisrt application,
> > > link it against RTEMS libraries, and get up and running.
> > > At this moment, he/she should not be worried about
> > > configuration, init task, stack size, prority, etc.
> > >
> > >   int main( int argc, char**argv )
> > >   {
> > >       printf( "Hello World\n" );
> > >       return 0;
> > >   }
> >
> > I would eventually like to get to this but for now just want
> > it to be easier to port UNIX applications.  I think that
> > getting better support for main()-style tasks is a big step
> > in that direction.
> >
> > The next logical step (to me) is to remove main from the BSP and
> > make it the initial task.

Yes, but now one must ask: where does argc and argv come from? This is
an issue for me at this time. We got dejagnu working and have managed to
run most of the libgcj regression testsuite on our targets. Except that
it looks like the mauve test executables expect arguments. Doh! I should
I get these arguments into the target? I have several possibilities in
mind, but I would like to see RTEMS implement some documented approaches
to do this. I could then code up the one that makes the most sense into
the expect scripts.


> >
> 
> Sounds good.
> 
> 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