[ECOS] Re: Any shell available?

[ECOS] Re: Any shell available?

[Anthony Tonizzo]

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 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. It would be a good way to test quickly a new version
of the code, because the application (nimbler in size, because all the kernel
is already running on the target as part of the shell) can be compiled on the
host, loaded (perhaps remotely) and then run. Of course when everything is
said and done, you will eventually compile your application with the kernel
and drop  the shell, but my point is that the former does not preclude the
latter.

vxWorks does it, why shouldn't eCos?

Yes, the two systems are different, different customers, different design
and all that goes with it, but there is nothing technical that prevents a
shell to be written for eCos. Besides, the  topic has come up several
times already, and the answers that have been  given so far for the lack
a shell in eCos are, in my humble opinion, neither convincing nor conclusive.

I can even envision a world in which, for those embedded systems that can
tolerate the extra requirements, RedBoot itself is put out to pasture and it
is replaced by a kernel with shell.

Regards
Tony

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

Re: [ECOS] Re: Any shell available?

[Andrew Lunn]

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

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

Re: [ECOS] Re: Any shell available?

[Luis Friedrich]

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.
Therefore, in order to load a program you'll have to start all over 
again, OS functionality plus application.

Friedrich


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

Re: [ECOS] Re: Any shell available?

[Andrew Lunn]

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

Re: [ECOS] Re: Any shell available?

[Anthony Tonizzo]

Andrew:

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

Agreed. Process management is impossible, and thus a real shell
will be impossible. But something based on objloader is still better
than nothing especially if your tasks are reasonably well behaved and
are not expected to die on you all the time, leaking memory all over
the map.

A possible implementation of the "kill" command in the shell would
call the  library_close() function inside the blob, and if the user is
judicious,
it can be used to try to reclaim as many resources as possible. In other
words, you must reclaim your own garbage, do not expect the OS
to do it for you. This "thread desctructor" is not  perfect by any
stretch of the
imagination, but a first step  in the right direction, and with time we can get
to a point where the memory leaks that result  from terminating a process
might be kept reasonably low.

In the case in which the thread dies a sudden death, there is little that
can be done without an MMU and per-thread paging anyway. And we really
do not want to go there.

Also, as you correctly suggest, the ability to run a script upon startup (a la
RedBoot) could make this "poor man's shell" a good boot loader: Instead of
recompiling and reflashing the application with the kernel, you instruct the
startup script to load the application upon boot from an existing file system
(JFFS2 come to mind.) That way multiple copies of the application can be
kept, and you can boot whichever one you prefer.

Cheers
Tony

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

Re: [ECOS] Re: Any shell available?

[David N. Welton]

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

A system like Erlang manages to have "processes", a shell, and a lot of
other things typically associated with real processes all inside one big
process...

-- 
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

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

Re: [ECOS] Re: Any shell available?

[Ilija Koco]

Frank Pagliughi wrote:
> Ilija Koco wrote:
>
>> Zimman, Chris wrote:
>>
>>> We've actually written a small shell for eCos that we use internally.
>>> There's no objloader support for our platform yet (AFAIK), but we use
>>> something similar to the RedBoot_cmd() syntax to bring in commands to
>>> the shell.  There's a "ps" clone, mount/unmount for the filesystems, 
>>> ls,
>>> etc.
>>> There's no scripting support, but there's no reason it couldn't be
>>> added.
>>>
>>> If anyone is interested, let me know and I'll see if I can pack it up
>>> into something exportable.
>>>
>>>   
>>
>> Seems nice. I was about to suggest something like this. Maybe add 
>> some networking stuff like ping, ssh, ftp, etc (All 
>> selectable/configurable by menas of cdl).
>> Ilija
>>
> Having just finished a vxWorks project, I kind of miss their shell for 
> some quick debugging features. Theirs is not a Linux-style bash shell 
> or anything similar. Rather, it's a thread within the single target  
> process that acts like a C/C++ interpreter. The OS is loaded at 
> boot-up, but application modules can be dynamically loaded and 
> unloaded while the target is running.
That's the general idea a thread that executes some unix like commands.
>
> You can call indvidual functions at the command line. All stdout is 
> sent to the command line and when the function completes, the shell 
> reports the return value. Just like working with an interpreted 
> language. Then you can recompile just your module and reload it while 
> the target is still running.
>
> When done debugging, you can then compile the OS and app all together 
> in one executable (like eCos) without the debug & shell threads.
Or meybe leave a shell with only "non-debugging related" commands" ls, 
ps, ping.
>
> It's really handy for quick and dirty debugging.
>
> Frank
>
>
>


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

Re: [ECOS] Re: Any shell available?

[Ilija Koco]

Zimman, Chris wrote:
> We've actually written a small shell for eCos that we use internally.
> There's no objloader support for our platform yet (AFAIK), but we use
> something similar to the RedBoot_cmd() syntax to bring in commands to
> the shell.  There's a "ps" clone, mount/unmount for the filesystems, ls,
> etc.
> There's no scripting support, but there's no reason it couldn't be
> added.
>
> If anyone is interested, let me know and I'll see if I can pack it up
> into something exportable.
>
>   
Seems nice. I was about to suggest something like this. Maybe add some 
networking stuff like ping, ssh, ftp, etc (All selectable/configurable 
by menas of cdl).
Ilija

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

RE: [ECOS] Re: Any shell available?

[John Carter]

On Wed, 31 May 2006, Zimman, Chris wrote:

> If anyone is interested, let me know and I'll see if I can pack it up
> into something exportable.

I would be interested.

Our Rich Cousins over in Fixed Infrastructure use embedded Linux and are
forever boasting how the debug shell they have written has saved them
oodles of time.

We are the Poor Church Mice mobile devices developers using eCos.

Even if it is just the crude outline it would be a good start.


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

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

RE: [ECOS] Re: Any shell available?

[Zimman, Chris]

We've actually written a small shell for eCos that we use internally.
There's no objloader support for our platform yet (AFAIK), but we use
something similar to the RedBoot_cmd() syntax to bring in commands to
the shell.  There's a "ps" clone, mount/unmount for the filesystems, ls,
etc.
There's no scripting support, but there's no reason it couldn't be
added.

If anyone is interested, let me know and I'll see if I can pack it up
into something exportable.

--Chris

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Anthony
Tonizzo
Sent: Wednesday, May 31, 2006 12:43 PM
To: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Re: Any shell available?

Andrew:

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

Agreed. Process management is impossible, and thus a real shell
will be impossible. But something based on objloader is still better
than nothing especially if your tasks are reasonably well behaved and
are not expected to die on you all the time, leaking memory all over
the map.

A possible implementation of the "kill" command in the shell would
call the  library_close() function inside the blob, and if the user is
judicious,
it can be used to try to reclaim as many resources as possible. In other
words, you must reclaim your own garbage, do not expect the OS
to do it for you. This "thread desctructor" is not  perfect by any
stretch of the
imagination, but a first step  in the right direction, and with time we
can get
to a point where the memory leaks that result  from terminating a
process
might be kept reasonably low.

In the case in which the thread dies a sudden death, there is little
that
can be done without an MMU and per-thread paging anyway. And we really
do not want to go there.

Also, as you correctly suggest, the ability to run a script upon startup
(a la
RedBoot) could make this "poor man's shell" a good boot loader: Instead
of
recompiling and reflashing the application with the kernel, you instruct
the
startup script to load the application upon boot from an existing file
system
(JFFS2 come to mind.) That way multiple copies of the application can be
kept, and you can boot whichever one you prefer.

Cheers
Tony

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

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