Re: [lwip-devel] Extended udp_recv callback

[Jonathan Larmour]

bill wrote:
> Just a thought: Why not put the netif in the pcb so it's available
> everywhere?  If you need it here, sure enough someone will need it somewhere
> else some day.  This would save the overhead on the call making it a
> one-time store.  And it wouldn't affect lwIP application code.

If you have multiple interfaces, i.e. multiple netifs, you can receive
incoming packets to the same PCB from different netifs. Assuming the PCB
isn't bound to a particular IP address, and so a particular netif.

>Jakob Stoklund Olesen wrote:
>> 
>> I would like to add two arguments to the udp_recv() callback function.
>> I am receiving multicast and unicast UDP packets, and I would like to
>> know the destination IP address and receiving interface.>>
>> The new prototype would look like this:
>>
>> typedef void (*udp_callback_function)(void *arg, struct udp_pcb *pcb,
>>                                       struct pbuf *p,
>>                                       struct ip_addr *addr, u16_t port,
>>                                       struct ip_addr *dst_addr,
>>                                       struct netif *netif);
>>
>> I have a patch to make this change. My question is: Should I go ahead
>> and change the prototype directly, or should I make it conditional on
>> an
>> UDP_EXTENDED_CALLBACK macro in opts.h?
>>
>> The code would be a lot cleaner without the macro, and users can easily
>> add the two extra arguments to their own udp_recv callbacks.

I'll let Kieran decide about the desire for backward compatibility in the
raw API. But it might be possible to temporarily use a PCB flag to decide
which to use. So code in udp.c might become something like:
if (pcb->flags & UDP_FLAGS_RECV_LEGACY)
  pcb->recv(pcb->recv_arg, pcb, p, &(iphdr->src), src);
else
  pcb->recv(pcb->recv_arg, pcb, p, dstaddr, dstport, &(iphdr->src), src);

Then the existing udp_recv() would set UDP_FLAGS_RECV_LEGACY, and a new
function, maybe something like udp_set_recv_callback() would be the same as
the existing udp_recv() but have the extended function signature.

Then in a later lwIP release, udp_recv() and the PCB flag could be removed.
It's just a thought anyway.

Less officially, you have the pbuf...

>> Is it OK to use a typedef for the function prototype? I have noticed
>> that the full abstract prototype is used in many places.

I don't see any reason why not personally.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine