On Jun 27, 2006, at 2:29 PM, Pavel Cahyna wrote:

If we're going to rework / add mbuf APIs, I'd like to propose  
something a little more radical...

- Make mbufs an opaque type... "typedef struct mbuf *mbuf_t;", hide  
the definition of "struct mbuf", and use accessors / mutators that  
have well-defined semantics to make it less easy for mbuf users to  
screw themselves.

- mbuf_data() would return a const void *.  If a user wants a  
writable buffer, then mbuf_mutable_data() would return a void *.   
This would allow us to encapsulate the whole "make writable" thing,  
and allow us also to keep some state in the mbuf itself to possibly  
avoid unnecessary iterations over the chain (if it's already  
mutable).  Anyway, this would also force us to const poison the  
networking code, which in turn would help the compiler generate  
better code which in turn could lead to better performance.  It's all  
good.

Take a look at /System/Library/Frameworks/Kernel.framework/Headers/ 
sys/kpi_mbuf.h on a Mac OS X 10.4 system for what I think is a good  
starting point for where I think we should go in this regard.

> On Tue, Jun 27, 2006 at 11:54:21AM -0500, David Young wrote:
>> On Wed, Jun 21, 2006 at 09:47:49AM +0200, Pavel Cahyna wrote:
>>> For most of the uses the version returning const should be  
>>> enough. Code
>>> which needs a writable pointer to the mbuf could use a mptr_rw  
>>> macro,
>>> which would do a m_makewritable on the returned region. Or such code
>>> should be converted to m_copyback, then mptr_rw wouldn't be  
>>> needed. There
>>> shouldn't be many places where writing to mbufs is necessary.
>>
>> Careful: m_makewritable does not guarantee that the mbuf is  
>> contiguous,
>> only that each segment is writable.  That deserves to be explicitly
>> mentioned in mbuf(9); I keep forgetting to add that.
>
> Yes, I'm aware of that. A question is if the mptr_rw macro would also
> ensure a contiguous region, or if there should be a separate
> mptr_rw_pullup macro. (At this point the number of possibilities  
> becomes
> large enough that it might be preferable to have just two macros,  
> mptr and
> mptr_rw, with an extra "flags" argument, and make the _pullup  
> variants one
> of the flags.)
>
> Pavel

-- thorpej