removing taskvares (was Re: rtems_filesystem_current issues)

Fernando RUIZ CASAS correo at
Sun Oct 27 20:52:26 UTC 2002

Hi all,

    The only goal of user_env was to give a clean solution at the chdir() problem 
in ftp session and shell session. 

    Cris has writed that the task var is a very bad solution and the task extension was the very
good solution. I have employed the rtems solution and after this a chroot() was been implemented.

    I think that it is better rewrite the non safe functions like umount() and other in order to
solve this concern.

    Please, don't touch the newlib REENT because a lot of code don't need this and the newlib uses
intensively the REENT struct. 

    The Russian Navy has a very good procedure. Don't touch if it doesn't fail.

    Solving the nonsafe problem is a very good solution. Add a new source of problems is a bad

    Changing the task_var to task extension is better in order to performance. Change it.

    Change REENT is not neccesary to improve performances. When the new ideas arrive it is necesary
change the newlib internal vars?

    Every thing in every place.

    This is only a poor opinion after read your emails.


home:correo at
now in France: fernando.ruiz at

On Sun, 27 Oct 2002 12:32:10 -0800 (PST), Eric Norum wrote:

> On Saturday, October 26, 2002, at 06:32  PM, Chris Johns wrote:
> > Till Straumann wrote:
> >>
> >> Absolutely - one obvious solution would be attaching something like
> >>
> >> struct reent_rtems {
> >>     struct _reent _reent;
> >>     /* could have some padding here *7
> >>     struct userenv uenv;
> >> }
> >>
> >> to the _REENT pointer.
> >>
> >
> > I sort of agree. The introduction of a rtems_reent and a rtems_REENT
> > variable was something I was also considering. We need to keep the code
> > in the context switcher for the _REENT (_Thread_Set_libc_reent), and 
> > add
> > new code for rtems_REENT (_Thread_Set_rtems_reent). I do not think you
> > can change the meaning of _REENT without newlib being effected.
> >
> > It maybe a good time to look at the other uses of taskvars and remove
> > them. The C++ wrappers, shell, and RPC code.
> >
> I've never been really happy with the addition of task variables to 
> RTEMS.   I added them a few years ago when the initial steps of moving 
> EPICS to a non-vxWorks platform were being made.  The EPICS IOC code 
> used task variables so it seemed like a good idea to add them to RTEMS. 
>   SInce then EPICS has been rewritten so that there is no longer any 
> need for task variables.  Unfortunately they've pushed their way into 
> other places, as noted above.
> I'd really like to find a good alternative that would work without 
> slowing task context switches and be efficient for application programs 
> to use without exposing too much of the RTEMS internals to the 
> application programmer.  Perhaps a 'big-enough' array of void * inside 
> the RTEMS TCB and an agency (run by OAR somehow??) to assign 
> 'well-known indices' of these array elements?  e.g. 
> etc.  There would be a macro/inline function
> void **rtems_taskvar_get(int taskvar_index);
> Since the accessor method would be very fast, applications could for 
> example use:
> #define rtems_rpc_task_variables ((*(struct 
> _rtems_rpc_task_variables**)rtems_taskvar_get(RTEMS_TASKVAR_RPC))
> This is just some early morning musing.  The idea of adding more 'magic 
> numbers' isn't very appealing to me, but neither is the existing O(n) 
> increase in context switch time for n task variables.....
> -- 
> Eric Norum <eric.norum at>
> Department of Electrical Engineering
> University of Saskatchewan
> Saskatoon, Canada.
> Phone: (306) 966-5394   FAX:   (306) 966-5407


More information about the users mailing list