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 <[EMAIL PROTECTED]> -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
