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


On Wed, 2005-11-30 at 11:34 -0600, Grant Edwards wrote:
> 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.

I agree with all of this.  What I was trying to point out is that
a generic (off-the-shelf) SSH or telnet server which the user would
use to just connect and "run" something does not make any sense.

Of course (as I did mention) connecting some part of the application
via a CLI which is exported by SSH or telnet certainly does make sense,
hence the ability to do this in RedBoot.

I also agree that a generic framework would be useful - I just don't
have the time myself to create and donate it :-(
 
-- 
Gary Thomas <gary@mlbassoc.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]