[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
network based console?
- Date: Sat, 13 Sep 2008 11:09:22 -0700
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: network based console?
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.
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
> 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.
> P/s: one comment below
> Thomas Doerfler (nt) wrote:
>> 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?
>> 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).
>>> -- 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.
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>>> rtems-users mailing list
>>> rtems-users at rtems.com
> rtems-users mailing list
> rtems-users at rtems.com