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

[Rosimildo da Silva]

From: Charles-Antoine Gauthier <charles.gauthier at nrc.ca>
To: rtems-users <rtems-users at oarcorp.com>
Sent: Tuesday, August 29, 2000 11:07 AM
Subject: Re: [Fwd: Re: feedback requested on proposed new directive]


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


We all know that the main() function used by RTEMS' startup
is a major pain.  I am ready to celebrate with six pack beer
when it goes away. :-)


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

Well, I do not think and changes much.
Why applications should supply init_tasks, anyway.  ???

>From a programmer standpoint, I expect the system to call my application
entry point, main(), and I'll do the initialization of my specific tasks
from there.
Just like Linux, WIndows, OS/2, DOS, ( put your OS here ).

The init_task() should be some kind of "super duper task". It is a RTEMS,
POSIX, iTron task at same the time. It should work with any API.

>
> Was this discussed? Did I miss some threads?
>


yes, we discuss this before, .....



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

I do not think that any user code would run until the main() is called....
so we might be ok.

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

It could be provided along with the main() function. The init_task
would use the global values. If you do not provide them, along with
your main() function, the link would use the module in the library
with the default values.

/* default_args.c   */
char *global_argv[] =
{
     "rtems"
};
int global_argc  = sizeof( global_argv ) / sizeof( global_argv[ 0 ] ) ;
/* end default_args.c */

int main( int argc, char **argv )
{

}

Rosimildo.