> Hi!
> 
> Sorry for the slow replies!
> 
> I had something like interrupts(like Blaz Antonic suggested) in mind instead of polling. 
> 
> I was also wondering what would happen if packets came in faster than we can process. Will i lose
> the packets.When I tested the PPP code in Linux before trying it on ELKS, I somehow seemed to be
> getting empty frames etc. The same code when complied for ELKS worked fine. I am not sure what the
> problem was. 
> 
> I don't think the options negotiated in the LCP are 'do and forget'. I think the link properties
> need to stored. pppd could just negotiate options, store and exit. The network layer specific NCP
> could then take over but I am not sure where it goes. If its in the kernel, how should i go about
> it?
> 
> Thanks,
> Pooja
> 

I just had a glance to the PPP rfc and it seems that in order to have a
functional PPP, LCP NCP packets should be interpretted all times. The
straightforward way of doing it is to have a pppd demon reading the
packets from the serial line doing the processing and passing it to the
above layer. For ipv4 in ELKS this means passing them to the ktcp demon.
This passing is that conserns me. This will probably be done throught a
UNIX socket. So for a process to get it's data we need many many task
switches and data copying(kernel -> pppd -> kernel -> ktcp -> kernel ->
process). So it is probably better for the PPP code and ipv6 code to be
added in ktcp.

Harry