Re: [lwip-users] udp (RFC!)

[Leon Woestenberg]

Hello all, in response to David,

> >
> >lwIP assumes that PBUF_ROM refers to static, constant data (such as
> >Read Only Memory devices).
> >
> >You cannot use it for data buffers within lwIP.
> >
> I'm not the one using it. It is already being used from within the
> sockets interface. And my claim is that this is a problem.
>
Agreed. The lwIP sockets layer is then violating the lwIP core API.

>
> By the way, I agree that your pbuf changes would be a good thing, but
> I'm not so sure that it will help in this particular case if you want to
> use a "classic" sockets interface. BSD style sockets always copy data to
> and from the sockets. If that's the interface we are supporting with
> lwip_sockets, then we should make it work that way. Otherwise it makes
> it very difficult to port sockets applications to lwip.
>
Correct me if I'm wrong, but I thought all BSD socket calls give their
buffer by reference. In that case, we could still deploy the zero-copy
tactic used by lwIP, but have lwIP do a copy-on-demand in case it
cannot handle the data directly (during the blocking call).

> I have seen one approach to pbufs where you can allocate a pbuf and pass
> in a function which gets called during pbuf_free() to allow the
> application to free the data buffer. This might be a good way to handle
> a PBUF_REF type.
>
My favorite approach would be to transparently copy-on-demand, where the
application can just assume any submitted data is non-refered-to after a
BSD socket call.

This offers full compatibility with the BSD socket API. Applications using
the
BSD socket API often have a statically allocated data buffer and do not have
to be rewritten to feature the free()-callback.

Regards,

Leon.