lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] Extended udp_recv callback


From: Jakob Stoklund Olesen
Subject: Re: [lwip-devel] Extended udp_recv callback
Date: Tue, 13 Jan 2009 17:21:51 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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

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

I like this idea. I would be nice to avoid #ifs all over the place.

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


/stoklund




reply via email to

[Prev in Thread] Current Thread [Next in Thread]