[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
network based console?
- Date: Sat, 13 Sep 2008 09:44:21 -0700
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: network based console?
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
IIRC printk calls a BSP-supplied function via the pointer
'extern void (*BSP_output_char)(char c);'
to print characters.
The BSP would output them via the serial port in polled mode.
Your BSP would have to either do nothing or print the characters
to a memory buffer.
> 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.
If you want to redirect just one tasks' stdio over a socket then
things become much simpler. I was assuming you wanted to
redirect the 'global console' which is shared by all threads.
Look into the telnet stuff. The 'shell' program spawned by
the telnet daemon (or executed by the telnet daemon -- IIRC
that is also an option) is configurable. You can wrap your
application and execute it from the telnetd daemon.
The only caveat may be what happens if the remote terminal
closes the session and the socket is shut down -- you'd have
to be prepared for that. IIRC I had added some hacks to
the pty driver to prevent it from deleting the running task
when the connection was closed.
> 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