Re: [lwip-devel] Extended udp_recv callback

[Kieran Mansley]

On Tue, 2009-01-13 at 17:21 +0100, Jakob Stoklund Olesen wrote:
> Jonathan Larmour wrote:
> > 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);
> 
> This is more or less what I have done, except I used a compile-time macro:
> 
> #if UDP_EXTENDED_CALLBACK
>         pcb->recv(pcb->recv_arg, pcb, p, &(iphdr->src), src,
>                   &(iphdr->dest), inp);
> #else
>          pcb->recv(pcb->recv_arg, pcb, p, &(iphdr->src), src);
> #endif /* UDP_EXTENDED_CALLBACK */
> 
> The problem with this approach is that now all the client code looks
> like this:
> 
> static void dhcp_recv(void *arg, struct udp_pcb *pcb, struct pbuf *p,
>     struct ip_addr *addr, u16_t port
> #if UDP_EXTENDED_CALLBACK
>     , struct ip_addr *dst_addr, struct netif *recv_netif
> #endif
>     )
> {...}
> 
> Not pretty...

I think a combination of the two approaches might be best:
 - add an extra callback to the API, something like pcb->recv_ext() with
an associated means of setting a handler for this callback. 
 - have a pcb->flag that selects whether to use the normal recv callback
or the extended recv callback.
 - have a compile time EXTENDED_RECV_CALLBACK definition that can be
used to compile the extended recv callback feature out if others don't
want it.

That way existing code doesn't need to be modified as the old callback
remains the same.

> > Less officially, you have the pbuf...
> 
> :-)
> That was also my first idea. You can't get the netif this way, though,
> and you have to parse IP options backwards...

Tricky, yes.

I feel a bit like this change shouldn't be necessary though.  I'm not
opposed to layer violations where there's good cause, but normally when
something like this crops up it's because something is being done in the
wrong way and I'd rather fix that.  How would this application be
supported in another environment?  E.g. what API is available for
mDNSResponder in places where it works already that we don't have in
lwIP?

Kieran