It tracks both the first mbuf and last mbuf, making it handy to use inside
functions that are interested in both. It also tracks length of data and
memory usage. It can be allocated on stack and passed to an mbuf
allocation or another mbuf manipulation function. It can be embedded into
some kernel facility internal structure representing most simple data
buffer. It uses modern queue(3) based linkage, but is also compatible with
old style m_next linkage. Transitioning older code to new type can be done
gradually - a code that doesn't understand the chain yet, can be supplied
with STAILQ_FIRST(&mc.mc_q). So you can have a mix of old style and new
style code in one function as a temporary solution.
Details
Details
- Reviewers
tuexen markj - Group Reviewers
transport network - Commits
- rGab8a51c45586: mbuf: provide new type for mbuf manipulation - mbuf chain
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/sys/mbuf.h | ||
---|---|---|
1698 | I was thinking of mc_foo() functions to be substitute for m_foo() functions in many places, with local variable named mc instead if two variables named m and tail, seeing mchain as an alternative to mbuf itself, rather than to mbufq. Also, to be fully consistent with mbufq the prefix should be mbufc_. Let me work on other things you noticed and let's come back to that later. |
sys/sys/mbuf.h | ||
---|---|---|
1730 | Why? The supposed usage of this KPI is that mc has just been allocated on stack. A prologue of a function that makes use of mchain, but was called by old code: foo(struct mbuf *m) { struct mchain mc; mc_init_m(&mc, m); |