This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
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