Hello,

back to this old topic, as SoC is finished and time for integrating the
project came...

On Tue, Jun 27, 2006 at 04:25:51PM -0700, Jason Thorpe wrote:
> 
> On Jun 27, 2006, at 4:19 PM, Pavel Cahyna wrote:
> 
> >Isn't it mostly what I have proposed? I have proposed mptr_rw returning
> >writable pointer, and mptr... returning const pointer.
> >
> >A difference is that the proposed macros would also do the cast to the
> >required data type, to be more similar to the current mtod() and at the
> >same time to be able to use sizeof on this type.
> 
> You proposed macros, which I don't like so much for this.  I would also
> rather pass in a real length, rather than using sizeof magic inside the
> macro itself.

I'm not a big fan of macro magic. But I think that in this case it is
justified. I wanted to have something to replace mtod with additional
sanity checks, similar to what yamt@ suggested for mtod. For this, a
function which returns void * and accepts a real length is not suitable,
because it won't automatically guarantee that the length is sensible.

In some cases a function accepting real length is preferable, I have added
this.

My experience with using the new API is that it is well suited for
replacing most of the current uses of mtod.

BTW I have looked at the Mac OS X mbuf KPI and wasn't impressed. There is
not much innovation (renaming struct mbuf * - > mbuf_t, m_ -> mbuf_ does
not count). I don't see what is gained by replacing the direct access to
struct mbuf members by accessor functions, especially when the semantics is
not well defined (how do the function that change mbuf length interact
with the packet length?), or not well chosen (mbuf_setdata? why does it
accept a pointer when it must set the data pointer to data inside the mbuf
storage?)

> I also would prefer different names other than mptr*().  I'm not really
> much of a fan of the current m_*() names either :-)

Let's discuss it in a separate thread.

Pavel