pkt: add functions to allocate packet data [WIP]#2322
Closed
miri64 wants to merge 1 commit intoRIOT-OS:masterfrom
Closed
pkt: add functions to allocate packet data [WIP]#2322miri64 wants to merge 1 commit intoRIOT-OS:masterfrom
miri64 wants to merge 1 commit intoRIOT-OS:masterfrom
Conversation
8541d2f to
5dff0c3
Compare
5dff0c3 to
e8d340d
Compare
Contributor
|
As said before, I don't like this. I think the problems (1) and (2) can be solved by a good pktbuf implementation and we gain a lot of benefits in terms of code readability and even more important efficiency when implementing network modules aka protocols. |
Contributor
There was a problem hiding this comment.
-DDEVELHELP must not shadow errors. Use puts("pkt == NULL, expect errors!").
Member
Author
Member
Author
|
Problem solved in #2285 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Alternative to #2285. Still WIP (tests need to be adapted).
There were two problems in #2285:
pkt->payload_datawas not thread-safe.The solution for both is more or less to keep
pktbufa void pointer oriented buffer and (for (1) specifically) to not putpkt_tstructs into it. This way every thread is responsible for their own instance ofpkt_tand a movingpayload_datais not the problem anymore. The header problem get's solved, since the internal organizing structure does not inherit frompkt_header_tanymore now.Since through this we lost some requirements for
pkt, I simplified it a little:pkt.htosys/net/includesince it haspktbufas dependency anyway (technically this is not due to a requirement-loss ;-))packedattribute frompkt_tsince it is not stored in thepktbufanymorepayload_protofrompkt_tsince I don't see any use-case for it and we save this way a few byte. It was introduced, since I needed a relationship betweenpkt_tandpkt_hlist_tto use a modified version of them aspktbuf's internal organizing structure.