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: Looking for these packages under eCos


In gmane.os.ecos.general, you wrote:
> On Wed, Nov 30, 2005 at 01:26:16AM -0700, Gary Thomas wrote:
>> On Wed, 2005-11-30 at 08:48 +0100, Andrew Lunn wrote:
>> > On Wed, Nov 30, 2005 at 11:21:22AM +0530, prashanthu baragur wrote:
>> > > Hi,
>> > > 
>> > >             I am just searching for these packages,
>> > > 
>> > > 1. SSH server
>> > > 2. Telnet server
>> > > 3. any shell application.
>> > 
>> > Nobody has contributed anything like this.
>> 
>> Furthermore, it's questionable if they make any sense for eCos.

The first two most certainly do.  The third (a generic,
universal "shell" of some sort) might not.

> It might not make sense, but it does keep comming up again and
> again.
>
> We know that executing "programs" is not possible. But there
> is no reason why functions cannot be called in responce to
> commands. 

Many of my applications (eCos and otherwise) have a simple CLI
interface that allows the user to control things and query
status via serial prot, telnet or ssh.

> What i think would be useful is some generic CLI code which
> you can register "command name":function() pairs to. It would
> handle command line editing, maybe history etc as well as
> doing the parsing of the input and call the function using the
> standard (int argc, char * argv[]) semantics.

Been there, done that on several occasions.  Sometimes it gets
disable before shipping "real" versions, sometimes it doesn't.

Even if there aren't any commands, merely making the output of
diag_printf() available via a telnet or ssh connection has
proven to be _extremely_ useful.  Monitoring and logging
diagnostic messages from 64 TCP ports is a hell of a lot easier
than doing the same thing for 64 serial ports.  :)

> Along with this there would be different modules which does
> the interaction with the user, ie basic IO. This could be from
> the serial port, telnet or ssh etc.

That's pretty much exactly what RedBoot does and what I've done
for myself in various different applications (usually using
something similar to the "table" scheme used to register
commands).  I see no reason why a "CLI framework" for eCos
along with a single-connection telnet server wouldn't be a
generally useful package (and not a large amount of work).  The
last one I did under eCos was pretty brain-dead: No command
line editting and single-character commands with no parameters
-- but even that has proven to be a lifesaver on a couple
occasions.

Doing an ssh server is more work, but if you limit it to one
connection it's not horrible.

> Since stdin, stdout, sterr are global, not per thread (i
> think), i think we would require a cli_printf() command which
> would be tied to the IO channel used to invoke the command.
> Per thread variables could make this easy.

-- 
Grant Edwards                   grante             Yow!  Well, O.K. I'll
                                  at               compromise with my
                               visi.com            principles because of
                                                   EXISTENTIAL DESPAIR!

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