This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Any shell available?


On Wed, May 31, 2006 at 08:51:50AM -0300, Luis Friedrich wrote:
> Andrew Lunn wrote:
> 
> >On Tue, May 30, 2006 at 06:02:28PM -0700, Anthony Tonizzo wrote:
> > 
> >
> >>Andrew:
> >>
> >>   
> >>
> >>>Now eCos has no concept of loading a program from secondary storage
> >>>and executing it. It has no concept of a program. It has no concept of
> >>>a process.
> >>>     
> >>>
> >>I am not sure I agree 100% with this statement.
> >>
> >>eCos has both the concept of file system (and hence we can extrapolate
> >>the concept of secondary storage) as well as the concept of process, given
> >>that a process can be loaded by the objloader package and executed.
> >>   
> >>
> >
> >I did wounder if anybody would bring up the objloader packege.
> >
> >Yes, we have a filesystem. However we don't have processes. 
> >
> >We have threads, but not processes. To me there is a big
> >difference. For one, a process has resource management associated to
> >it. If a process dies, or is killed, all the resources associated to
> >it are released. Memory is put back into the pool, file handles are
> >closed etc. Also, a process contains one or more threads. Killing a
> >process kills all the threads in the process. 
> >
> >Without having processes, from a pratical standpoint, you cannot have
> >programs which run to completion and exit. Thus you cannot have a
> >shell.
> >
> > 
> >
> >>I do not see anything wrong with an application (call it shell) that
> >>is capable of both accessing a file system as well as loading from
> >>that file system a file and running it.
> >>   
> >>
> >
> >To me, that is more like a boot loader and less like a shell, although
> >what you describe is somewhere between the two. To be a shell, what
> >has been loaded must be able to exist and be unloaded, and you must be
> >able to load something else which can exist and be unloaded,
> >add-infinitum. For this you need processes, not threads.
> >
> >              Andrew
> >
> > 
> >
> In other words you might say that you have only one process with the 
> application threads and the OS code all running together on the same 
> address space, and this could be called the program.

Address space is not the issue and uclinux proves the point. The Linux
kernel and all the processes run in the same address space with
uclinux. 

> Therefore, in order to load a program you'll have to start all over 
> again, OS functionality plus application.

What makes it a bood loader, not a shell.

However what Anthony is suggesting would allow multiple blobs of
object code to be loaded and executed simultaniously. And the blobs
can be loaded at any time, not just at boot time. It is more than a
boot loader.

However, there is no practical way to terminate all the threads
associated with a blob, unload it, and make sure it has released all
its resources. To do this you need processes. Without this you cannot
have a proper shell.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]