network based console?

[Gene Smith]

In my application I can just use printf, no problem. But what happens if 
you do call printk and there is no serial port enabled? I'm not sure on 
that.

Again, all I am wanting is a remote terminal (made by I assume telneting 
to rtems) that takes the stdout, in, and err from just my application 
(like gtkterm does now). I don't need it to accept standard shell 
commands like ls or whatever other commands the "rtems shell" can accept.

I thought maybe I can just enable the rtems telnetd and a pty and this 
will occur if serial console is disabled. However, it sound like it is a 
  lot harder after reading Till's comments.

-gene
P/s: one comment below

Thomas Doerfler (nt) wrote:
> Hi,
> 
> just to throw in my two cents: wouldn't it be possible to establish the
> pseudo-tty driver as "console" replacement? Iam sure this needs some
> tinkering, but might be worth a try.

Can you provide pointers on how to do this?
Would you still run telnet on the remote end?

> 
> Thomas.
> 
> 
> Till Straumann schrieb:
>> If you want to redirect your system console to a TCP/IP socket
>> then you have to consider a few gotchas:
>>
>>  - 'printk' will never be possible; printk normally uses a polling
>>    driver for the serial port enabling it to be called everywhere
>>    (w/o task context, from an ISR, before system is up etc.).
>>    Unless you have a second networking
>>    IF and implement a special polling driver + protocol stack there
>>    you're not going to have printk.
>>
>>  - you should be able to replace fds 0,1,2 with a TCP socket so
>>    that all stdio goes over that connection.
>>
>>  - HOWEVER: the RTEMS file-system per se is not thread-safe
>>    and RTEMS sockets are not. Therefore, you'd need to somehow
>>    add locking; so you'd probably have to write a small 'driver'
>>    wrapping a mutex lock/unlock pair around read/write from/to
>>    the socket.
>>
>>  - NOTE: RTEMS/newlib's FILE buffers are global, unprotected
>>    objects and sharing them among threads is not safe (unless
>>    you add locking yourself).
>>    BUT: the stdin/stdout/stderr streams/buffers are
>>    exceptional: every thread has it's own set of 3 buffers (all
>>    sharing the underlying file descriptors 0,1,2).
>>
>> HTH
>> -- Till
>>
>> Gene Smith wrote:
>>> Right now my stdin and stdout operations go in/out the serial port. 
>>> However, my serial port *must* go away since it is multiplexed with a 
>>> more essential function that replaces it. However, my ethernet tcp/ip is 
>>> working well now. Is it possible to setup a remote terminal using tcp/ip 
>>> that will act as stdin/stdout for my board running rtems? This would 
>>> mainly be for debug or control purposes and probably not kept in the 
>>> final version.
>>>
>>> In the past, I have used syslog to record debug messages on a remote 
>>> system (output only) via UDP. I see mention of a telnetd for rtems that 
>>> might allow me to connect to the rtems board but not sure that the 
>>> remote telnet terminal functions the same as the remote serial terminal 
>>> (ie, gtkterm, minicom, etc), i.e., printf's output to it and keystroke 
>>> are input back to rtems.
>>>
>>> I expect this is all bound in with termios and the console driver and 
>>> network driver but not sure how it all ties together or if what I want 
>>> is possible. I will keep looking. But any advance information or 
>>> comments would be appreciated.
>>>
>>> -gene
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>   
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 
>