submitting was Re: RV: Multiuser environmnet

[Fernando RUIZ CASAS (E-mail)]

-----Mensaje original-----
De: joel [mailto:joel]En nombre de Joel Sherrill
Enviado el: jueves, 21 de diciembre de 2000 14:47
Para: fernando.ruiz at ctv.es; Jake Janovetz
Asunto: Re: submitting was Re: RV: Multiuser environmnet



Jake,  The discussion has crept further down the email but
I am including you because the notion of user, group, and
current working directory changing on a "pseudo-process"
basis sounds similar to what the problems you had to
address on the ftpd server you wrote for RTEMS (Fernando
see c/src/libnetworking/rtems_servers for details.)

"Fernando RUIZ CASAS (E-mail)" wrote:
>
> -----Mensaje original-----
> De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Enviado el: jueves, 21 de diciembre de 2000 0:32
> Para: correo at fernando-ruiz.com
> CC: Rtems-Users
> Asunto: submitting was Re: RV: Multiuser environmnet
>
> 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.

For sure this should be detail with separately from the
process issues.  Ideally there would be a formal API definition
for your device so other drivers could be dropped in.  You
need to open this as a separate mail thread on the mailing list.

> > 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
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> Well,
>
>         I think about two ftp client sessions opened simultaneously
>
> What is that I need?

Just to make sure we are on the same page -- the ftp clients are
running on RTEMS, Right?

> First, current directory.
> I think about user id (with /etc/passwd database) and gid also.
> Filesystem root to prevent invalid access with anonymous login.(Is that
> possible?)

Also a process ID if you are going this far. :)

Hmm... are you familiar with the traditional unix way of handling this?
There is a magic variable "U" inside the kernel which points to
user process state information.  I am proposing a similar
variable for RTEMS (better less likely to conflict name).  All
"process" information would be put in the structure it points to.
There would be a global one by default and by calling a fairly simple
around rtems_task_variable_add() to indicate that a task wanted
its own version of this structure, a task could have its own
one of these.

This would allow each thread/task to elect into the "single global
procress" or have its own state.  This does not address my notion
of a pseudo-process that is really just a collection of threads but
I can begin to see mechanisms to do this.  For one, the C library
user task extensions could very simply be modified to have the
created thread/task inherit the process pointer of the "parent"
(i.e. creating) task.  This way once a task opted out of the
global process, all of its children would by default be part
of the same psuedo-process.

The data items you have identified would be the initial elements
in the structure.


> The system for a new shell session is the same protocol.
>
> What is that I need?
> I don't known 'a priory' before developping.

I think the key is to have the "user process structure" defined
with a handful of known elements.  When a global or static variable
is deleted and moved into the structure, simply change all references
to it.

> But I have already build the next procedures.
>
> int start_task_shell(char * name_task, /* to built rtems_name_build */
>                      char * name_device_in,char * name_device_out, char *
> name_device_err,
>                      rtems_priority p, rtems_stack_size s);
>
> After this the device works like unix terminal.
>
> The new task get a login success and after a get_line process line cmd is
> runned.
>
> There you can starts commands with the standard program header
>
> int main_ls(int argc,char * argv) {
> ...
> }
>
> only a register command is necesary
>
>  int shell_add_cmd(char * name_cmd, char * help_topic,char *
> usage,shell_proc_t proc);
>
> the call is shell_add_cmd("ls","dir","ls [mask_name] # list the files in a
> directory",main_ls);

Is this using Chris Johns' port of the BSD file commands?

> All of this is the same that in monitor but monitor works only in
> /dev/console and
> I can run run_monitor_init(0) like another command in the shell that works
> with /dev/console.
>
> This is because monitor works with STDIN_FILENO,STDOUT_FILENO &
> STDERR_FILENO (0,1,2 respectively)
>
> I need the a file open table (chain linked table perhaps) for every shell
> session.

The file descriptors (open and closed) are in an array.  If some
bookeeping
info is added about which process/thread opened it, would this be
sufficient?
You can scan the array.   There is unlikely to be more than 20-100
anyway.

> I need open the new stdin,stdout & stderr with
>   stdin=fopen(name_device,"r+")
>
> in shell_task_stark but I can't use read(0,buf,1) because 0 isn't the
fileno
> assigned at the new stdin file.
>
> I need make freopen(name_device,"r+",stdin) in order to keep the fileno 0
> like STDIN_FILENO.
>
> With a local session file open table the problem is resolved.
>
> I think about all of this like a REENT structure but a SESSION structure
and
> changes the address with every task switch.
>
> I can think also in a middle solution that is keep every SESSION entry and
> changes all the entries every time that the task changes
>
> (A little of overhead but that is better as nothing).

Your SESSION structure is like my user process structure. It is better
to identify the information required, put it in that stucture and change
everwhere to be dereferences.

> The point of discussion process/set of task not is important in this kind
of
> environments without memory separated process.

uCLinux has no memory protection but has the notion of processes. Older
UNIces did this also.  I have used 8086, 68000, and 80186 unix boxes in
the OLD, OLD days.  The semantics are important and it leads nicely to
a path of dynamically inserting services into the RTEMS box.

> If you can access into the other memory process you haven't the real
> process.

No but you have the full semantics which makes it easier to port
packages that fork processes.

> What is the semantics for a new_process? I don't know.

Think in terms of a UNIX process -- memory protection is only one part
of a process context.  pid, gid, uid, current directory, effective
gid/uid.  Some of the state like "errno" is already in newlib's REENT
structure so we don't have to worry about that.

> What kind of session functions variables are possible?
>
> Thanks in advance for your appreciated answer.

No problem.  This is fun.  FYI I am technically in the holiday season
now
and will only answer sporadically. :)

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


Thanks, Joel, Jake and of course Chris Johns and all the rtems-users
for your colaboration. The sources from BSPs are published to comunicate
at all the users and the users makes the best approach in each application.

My idea is build a 'bash' executer with redirection, background process,
batch processes (shell scripts for system configuration) etc...

My problem is that SH1 not is ported a LINUX , uLInux or similar but
I want the same (more or less) performances almost in the user side.