PPP via message queues

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Thu Oct 25 19:36:46 UTC 2001

Thanks Mike,

I took the device driver approach, my code creates a device file for
pppd to use, then feeds data thru it via the read & write device
driver calls.  I found it helpful to pass the open, close and ioctl
device calls down to the respective rtems_termios_* functions.  I've
not completely confirmed its operation, but pppd is sucessfully
sending packets and issuing read calls.  I'd be glad to buy a beer for
whomever designed & implemented the RTEMS device driver interface, its
rather nice.

Do you know if the RTEMS pppd cares about 

 * wait_input - wait until there is data available,
 * for the length of time specified by *timo (indefinite
 * if timo is NULL).
    struct timeval *timo;

in sys-rtems.c?  I implemented a routine to at least send the signal
when data is ready, but I don't know how important it is.

Also, the telnetd code supplies a device driver providing something
pty-like, would it be reasonable to defer the RTEMS pppd pty related
code to the telnetd pty driver?


 > Hi Greg,
 > I did the last ppp upgrade to the current version 2.3.11.  I left
 > all the pty code in the source but currently RTEMS does not
 > support this.  In the future, I would like to investigate it since
 > dial on demand requires the use of a pty.
 > I guess the way I would try doing what you require would be to create
 > your own serial device driver.  This would allow the pppd code to remain
 > unchanged and the serial driver would be responsible for posting messages 
 > and events.  PPPD requires the serial device driver to be task driven 
 > so I think this would work.  Look at the lib/libc/termios.c file to see 
 > how RTEMS uses the rx and tx daemons for task driven serial drivers.
 > You may have to modify some data values in the termios data structure to
 > ensure the termios functions post events to your driver tasks.

More information about the users mailing list