[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] pbuf handling / possible bug?
From: |
address@hidden |
Subject: |
Re: [lwip-users] pbuf handling / possible bug? |
Date: |
Wed, 05 Aug 2015 22:27:23 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
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