address@hidden wrote:
Ed Sutter wrote:
Ok, I see what you're talking about in pbuf_header(). I don't know
the history
of the code to comment on whether or not the change should be in the
master
code base; but it would seem to me that if this is forcing a driver
to use
the memcpy loop to build the pbuf chain, then it would be a good
improvement.
The reason pbuf_header can't expand to the front is that it doesn't
know where the memory area that the PBUF_REF points to starts. While
shrinking works as long as p->len is > 0, expanding to the front
doesn't work without another pointer in the pbuf struct that tells us
the original ->payload pointer.
Well it can work, it just makes assumptions about code correctness. But
it is potentially ok to assume people can write valid code!
> The way to prevent memcpy is to allocate a PBUF_POOL (of the maximum
size) and pass the ->payload pointer to the MAC which can store the
receive data directly to that location. This method has some
disadvantages though: a) with most MACs, you cannot use chained pbufs
for receiving and b) you cannot use this method with MACs that have
internal receive buffers.
Just so you know: changing this _is_ on the to-do-list somewhere, but
I think don't even know whether there is a feature-request for this
somewhere...
There is task 7896 for it.