submitting was Re: RV: Multiuser environmnet
joel.sherrill at OARcorp.com
Wed Dec 20 23:32:03 UTC 2000
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.
> 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
> 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
> I have a /dev/flash that works very well.
> What is the place for this kind of things in RTEMS? (I want contribute with
> 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
> after in imfs.h define
> (I think that this is right. I write you in Windows. I dont have the sources
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
> is created where a new memory is malloc'ed and its pointers is changed every
> 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
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
More information about the users