network based console?

[Till Straumann]

Another idea: if you're just interested in stdout/stderr
then it could be better & easier to use a UDP socket
or e.g, the syslog facility.

T.

Gene Smith wrote:
> 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
>>>       
>>     
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>