PPP via message queues

[gregory.menke at gsfc.nasa.gov]

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).
 */
void
wait_input(timo)
    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?

Gregm


 > 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.
 >