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

[Joel Sherrill]

Rosimildo da Silva wrote:
> 
> 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. :-)

I can certainly agree that finding the magic sequence of initialization
that satisfies main(), RTEMS, device drivers, etc has certainly
been an ongoing challenge. :)

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

Tradition.... Tradition... How did this tradition get started? 
I'll tell you... I don't know.

<apologies to Fiddler on the Roof :)>

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

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

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

Would init()/fini() get called in these cases if main were at the
application level?

Given the above scheme it would if USE_INIT_FINI were defined in bsp.h.

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

One minor gotcha is that NO C++/Ada/Java? code should run until after
main().

> > 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 )
> {
> 
> }

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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985