RTEMS shell and chdir

[Joel Sherrill]

On 7/15/2014 6:05 PM, Peter Dufault wrote:
> On Jul 15, 2014, at 17:44 , Joel Sherrill <Joel.Sherrill at oarcorp.com> wrote:
>
>> On 7/15/2014 4:02 PM, Peter Dufault wrote:
>>> A friend started trying RTEMS and noted that the RTEMS shell doesn't work as he expected - each shell maintains its own current working directory.   Furthermore, a "chdir()" in a routine that then creates a shell doesn't get the working directory from the "chdir()".
>>>
>>> Searching about "current working directory" and "pthreads" or POSIX threads results in Linux and other man pages that state that the current working directory is shared across all threads in a process.  The RTEMS shell seems to be calling "getcwd()" to get back the directory for the shell.  Is there a single current working directory in RTEMS?  Should "chdir" in one shell result in all shells having a different current working directory?  How does it work now?
>> POSIX has the concept of a per-process environment. RTEMS has that
>> same concept but since the entire application is one process, a change
>> to the per-process environment could impact threads in a way that
>> you don't want.
>>
>> Thus you can set a thread to have a private per-process environment.
>> This lets a thread have a separate uid, gid, chroot(), cwd() and a few other
>> characteristics.
>>
>> The shell and ftp daemon use this feature. When you login, you actually
>> get a user id. I think fileio (for sure telnetd) example let you login
>> as root
>> or rtems and you have different file access permissions.
>>
>> By default, all threads have the same per-process variables.  Which
>> is POSIX compliant.
>>
>> Your friend was smart enough to recognize that this wasn't POSIX
>> behavior.  But since you can have multiple shell instances, it does
>> make sense that one chdir() only impacts that one shell.
> OK, but am I right that getcwd() works differently in one thread than another (I only briefly looked at the shell code, and I thought it was calling getcwd().) in the same process?  Is that POSIX compliant?  Is there a way to force all threads in RTEMS to have the same per-process variables since there is only one process?
Only tasks/threads which make a call to rtems_libio_set_private_env()
have this characteristic. By default, a thread shares the single application
(e.g. process wide) per-process variables. So, by default, the behavior is
POSIX compliant.

By default, you get one set of per-process variables. If you call
chdir() in one thread, it changes it for all threads in the system.
However, if you call chdir() in a thread that has invoked
rtems_libio_set_private_env(), it only impacts that thread and
that thread is not impacted by other threads calling chdir().

The shell uses a non-POSIX compliant call to provide each shell instance
with its own set of per-process variables. The shell does this because
you can have two instances of the shell running simultaneously. This
allows those instances independence for cwd, root directory (chroot()),
user id, group id, file access permissions, and umask.

This feature is used in the shell and ftpd. There is no way to turn
that off for those specific support libraries.



It is a rarely used feature but useful when you want it.
>>> Peter
>>> -----------------
>>> Peter Dufault
>>> HD Associates, Inc.      Software and System Engineering
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>> -- 
>> Joel Sherrill, Ph.D.             Director of Research & Development
>> joel.sherrill at OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available                (256) 722-9985
>>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>

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