submitting was Re: RV: Multiuser environmnet

[Joel Sherrill]

correo at fernando-ruiz.com wrote:
> 
> -----Mensaje original-----
> De: Fernando RUIZ CASAS (E-mail) [mailto:fernando.ruiz at ctv.es]
> Enviado el: lunes, 18 de diciembre de 2000 19:47
> Para: 'Rtems-Users (E-mail)
> Asunto: Multiuser environmnet
> 
> I am working around a multiterminal environment.
> I need manages remote terminals (like telnetd) but
> I have a little problem.
> 
> The shell task starts with a termios io-device
> 
> I open a new stdin,stdout & stderr with the new device.
> 
> (Only fopen, I can't freopen...)
> 
> All works well but:
> 
> The prompt shows the currentdir like Linux.
> 
> The system store this in a GLOBAL variable
> 
> rtems_filesystem_current (and umask also).
> 
> When a user exec chdhir all the users in the systems changes.
> 
> I find in libc that with a extension all the global variables are
> moved at reentrants variables with impure_ptr (_REENT).
> All of this will be easy if the enviromnet fs variables are pointers and
> not GLOBAL VARIABLES.
> 
> With a little rtems extension is possible to give a pretty solution.
> 
> Is it possible think about of this?
> 
> Is there a best solution to avoid it?
> 
> Thanks in advance.
> 
> Anybody interested about of this?
> 
> The idea is to make a monitor (more user frienly, think linux) in every
> termios terminal.
> 
> This runs ok already.
> 
> With a litle telnetd server (easy) is possible build a complex remotely
> system managed.
> 
> /*------------------------------*/
> 20-12-2000
> /*------------------------------*/
> 
> I am working to build a remote multiuser environment.
> 
> With a owner packet system of network I can make now the
> same service (in order to run commands) that telnet.
> 
> Simultaneously I can move memory, exec remote commands, etc...
> 
> My final objective is a tcp/ip environment with a flash
> filesystem.
> 
> Your comments about of cache memory to simulate hard-disk are
> very appreciated but my idea is that the flash has not arm nor disk.
> I don't need a cache memory to simulate unix only a sector erase buffer
> to mantain double access (read write). The flash memory is only to
> store configuration files and new version programs and logs. Not is a ram
> memory. But I need to use it like ram memory in order to record the
> information.
> 
> I have a /dev/flash that works very well.
> What is the place for this kind of things in RTEMS? (I want contribute with
> this)
> and Xicor e2prom /dev/e2p, etc...

Without knowing the requirements/portability of the device driver
I can't say for sure.  But ideally it would be in libchip/nvmem
and work independent of BSP given a bit of target specific information.
 
> Now returning at the last e-mail.
> 
> What is the possible solution for the first problem?
> 
> I need patch base_fs.c in libc.
> 
> -------------- base_fs.c ------------------------
> Here I need convert rtems_file_system current into
>                     __rtems_file_system_current and
> 
> rtems_filesystem_current_p=(...*)&__rtems_filesystem_current;
> 
> after in imfs.h define
> (I think that this is right. I write you in Windows. I dont have the sources
> here)

Are you trying to identify state information that could
be viewed as "process" versus "thread/task" information?

If so, then I am happy to discuss what needs to be included
as a dereference off a single "process" state variable.
The key is defining the semantics.

Aside: I have considered the notion of "collections of threads"
as a pseudo-process. 
 
> -------------- IMFS.H --------------------
> #define rtems_filesystem_current (*(rtems_filesystem_current_p))
> (and more variables like umask, etc..)
> to make a compatible RTEMS patch.
> 
> In a new extension like libc.c every time in task switcher changes the
> global pointers at the new malloc'ed variables in every environment created.
> 
> All tasks point to global variable except if a new user session shell
> environment
> is created where a new memory is malloc'ed and its pointers is changed every
> time
> that the shell task gains the control.

This can be accomplished with the task variable functions as well.

> I can mantain several sessions of ftp (or my owner file server) with
> several current_directories (one per session).
> 
> But I need find a snapshot that contains this because everytime that
> I download the new snapshot I need make a fine work to build it all again.
> 
> This type of solution is neutral to RTEMS.
> 
> I dont know all the candidates to be maked pointer in lieu of static
> variables.

Define the requirements for your "process" and we can begin to 
identify them.  The key is keeping the semantics proper.

> Thanks for all.
> 
> Fernando RUIZ CASAS
> fernando.ruiz at ctv.es
> correo at fernando-ruiz.com

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