It might be desirable to make mbuf an opaque type whose members would be never accessed directly. This would require a richer set of accessor functions or macros, to be used by code which currently needs to access struct mbuf members. This code needs mainly to manipulate mbuf data area, so functions to get and set the data pointer and mbuf length are the most needed ones.

This opens a question: what to do with the total packet length, stored in the packet header? If such wrapper function changes the length of the mbuf, it could also change the packet length accordingly. An alternative is to not touch it and leave the work for the caller. The first possibility has a problem: what if the mbuf is not the first in the chain? Updating the packet length only if the mbuf has the packet header structure is inconsistent - the caller would need to check if he is responsible for it or not. Delegating the work to the caller always would mean that there is a possibility to produce an inconsistent chain. In that case, is there any benefit in making wrapper functions? One solution could be to provide the wrapper functions with an additional pointer to the packet header. This would mean complicating the API, but could probably work.

Given that we need the backward compatibility with the current mbuf structure for code imported from other projects, we don't have the possibility of freely changing its layout. This removes part of the motivation for such low-level API - being able to change the implementation. Given that, it is likely that the opaque struct mbuf will remain in the realm of dreams.