Details
- Reviewers
glebius gnn ae - Group Reviewers
network - Commits
- rS316206: [mbufq] add a concat method.
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
I noticed there's no mbufq_concat method. I may change this once I finish (start? :) the code using it.
(It's something in net80211 that's a ring of mbufs that I have to change to be a ring of mbufqs so I can store lists of mbufs per queue slot.)
Maybe the name without _all suffix will be better choice?
Also, since there are no protection from concurrent access to queues, I think this should be noted in the comment too. The caller must have exclusive access to both queues, otherwise it is possible to get the wrong result.
Andrey, all mbufq functions have not protection, so there is no reason to outline this fact in comments to this one.
(I'll fix the build issue, obviously)
The reason for saying _all() is to reinforce that the queue limits aren't paid attention to.
I was thinking of later adding a concat() being an O(n) operation that'll dequeue one at a time up until the destination queue is full, then return how many were transferred.
What do you two think?
For me the "all" prefix doesn't provide intuitive understanding that limits are ignored. I think it is just fine to have function as is, and keep the possible limit override in mind.
Looks like Jenkins didn't like this little change either. You should look into the build failure. I also agree with the removal of _all() from the function name.