This is the mail archive of the ecos-discuss@sources.redhat.com 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: VxWorks type embedded "shell" for eCos


On 06 Feb 2004 16:36:47 +0000
Nick Garnett <nickg@ecoscentric.com> wrote:


> Exactly. I'm partly playing devils advocate here. I want to be sure
> that there is a genuine need for this facility, and that it is not
> just being asked for simply because "that's what VxWorks does". I
> don't want eCos to be transformed into a VxWorks clone any more than I
> would like to see it made into a Linux clone. My other main concern is
> that it does not have a negative impact on the complexity and
> maintainability of eCos.
> 
> I'm certainly not against the kind of runtime controls being
> suggested. The system monitor I produced as the HTTPD demonstrator
> already includes some of them. However, eCos was not designed to be an
> interactive OS, so we must be careful not to let the demands of the
> shell cause us to elaborate the rest of eCos beyond what is sensible.
> 
> I would worry about the security of any system that had the shell
> still installed. Particularly if it were open to remote access. But I
> suppose that really depends on the application. For something that
> goes into an already secure environment, or where it is not an issue
> then leaving the shell in is no problem. But for something like a
> mobile phone or in a nuclear power plant things are very different.

Right, as a consumer user, I was really unhappy to discover that my
brand new ethernet ADSL modem, prompting a "Nucleus" Shell on :23.

This is saying enough on the estimated quality of the firmware !

> 
> I can see the usefulness of being able to do such things during the
> test and debug cycle. I'm not so sure about deployment, when it is not
> clear that anybody who knows anything about the shell will ever get
> anywhere near the failed device. But I suspect that we are thinking
> about very different usage scenarios.
> 

Cool may-be I could do some reverse stuff on my modem .... At least I've
discovered that they have twice the RAM needed to get the "Flash firmware" working ...

More seriously, deployment is a typical "enterprise" issue. While a
generic framework for that would be helpfull, I can't imagine any
commercial/designer force not wanting its pure one (and masterized
solution). Some may wants HTTP, other Plug-and-pray ... whatever.

Of course, there may be people wanting eCos, because of its license,
never contributing back, wanting the community to work for every
of their needs, even commercial ones ... Well that's not looks like
fair open-source. I do not throw a stone here, because may be I should
punish myself too ... Well that's another story.

> > Tornado came way after the basic shell. I have something basic running
> > already. It does much of the powerful things of the shell relative to
> > examination and monitoring of a running system. My shell object file is 54K
> > including debugging information! The actual .text segment size is a whopping
> > 2664 bytes of ARM code compiled. Relative to the symbols, yes they can add
> > up....but the point is that is is small relative to the total executable
> > size.

Boo, I've started eCos with the GDB-stubs-alone config. That was smaller, in respect with the offered feature of gdb scripting.

> 
> Looking at the symbols in a typical network application, I reckon the
> symbols in there would easily require a 50k table. Looking at the
> command processor in RedBoot and assuming that the shell would need
> similar functionality, adding the device drivers and infrastructure, I
> reckon 20-30k there. So maybe 100k was somthing of an overstatement, I
> still reckon 60-70k.
> 
> It depends on how deep you want to go into the system when
> debugging. Unlike VxWorks there is no clear division between eCos and
> the application, so it's not clear where the cutoff point between user
> symbols and system symbols comes. Being able to call system routines
> would be a useful feature. But it all depends on how the symbol table
> gets constructed.
> 

Is there a trick (macro ...) to get a kind of ABI optionnaly marked ?
(with malloc, open, close, cyg_ and the likes).

> Most of what is in the eCos executable to support GDB would also be
> needed to support the shell. Most of it is in RedBoot.
> 

Or in the appli, if it's ROM, and configured so.

> My main concern with regard to GDB is issues like the IO redirection
> that RedBoot does. Another issue is what happens if a shell, loaded
> via GDB, sets a breakpoint. Who fields the exception? What happens if
> GDB has also set breakpoints? What happens if the application is also
> fielding exceptions? It can get complicated.

Wep, the trick is that eCos had taken a completely different approach to
debugging. Our stubs are really great for system debugging, look inside
the protocol stack and even drivers. We have a full "kernel" debugger,
or "almost GOD-mode" debugger as I prefer to refer.

If you compare to the VxWorks equivalent carefully, you may found some
unusual tricks like "The protocol stack threads have a magic flag
preventing breaking ...". Yep, so eCos debugging is superior to Vx.
I may debug a memory full in the OpenBSD stack, without cutting my
roots at the same time, because my debug channel is network !

Implementing gdb_server eCos in a "limited" fashion (while reusing or/not redboot-eCos code) is surely possible. But if it's for general
purpose debugging, I still prefer the current situation ...

> 
> Stack backtrace can be hard, the code in GDB to do this is a twisty
> maze of heuristics -- and even then it doesn't always get it
> right. Breakpoints could easily use the existing GDB support code,
> allowing for the issues above.
> 

> 
> I'm not against the idea of a shell at all, in fact the more think
> about it, the more I think it would be a good idea. But I do want to
> make sure that it is being done for the right reasons and does provide
> some useful features.
> 

Nick, I shall agree.

-- 
Eric DONNAT

Silicomp Research Institute
http://www.ri.silicomp.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


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