Re: [lwip-users] pbuf handling / possible bug?

[address@hidden]

Michael Steinberg wrote:
> I'm using lwip version "1.41 stable" here

Yeah, well, you shouldn't. I know it's bad we don't have a newer release 
but 1.4.1 is really not very "stable" any more: there are a *lot* of 
bugfixes as well as new features in git master that you shouldn't miss.

I was always planning to get a 1.5 beta out but haven't found the time, 
yet :-(
I've just updated the news section on savannah to reflect this.

> I will try to come up with a bug for this. Maybe it is no bug after 
> all because I'm just misusing it, then I'm sorry.

I've already fixed the "line 417" bug. But if you find other occurances, 
please report them to the bugtracker. Sending them here is OK for a 
start but things tend to get lost here as I don't always find the time 
to monitor every mail, especially when bug reports are hidden in the 
third screen after scrolling down the mail on my phone...
> How can a custom RAM-pbuf possibly reallocate

Well, the "reallocate" (i.e. trim) functionality is not one of the 
features. At least not for now. That one was really a bug. The 
behaviours are more like this:
- RAM: TX buffer, in one piece, struct pbuf and its payload are 
contiguous memory (although the "in one piece" might be removed in 
future versions)
- POOL: RX buffer, can be chained (e.g. scater-gather-RX), struct pbuf 
and its payload are contiguous memory
- REF: can be anything pointing to volatile memory, struct pbuf is 
allocated on its own, payload can be anywhere
- ROM: same as REF but pointing to non-volatile memory (i.e. when 
queued, payload does not have to be copied)


I've just pushed a change trying to document this better in pbuf.h...

Simon