It would appear that the behaviour of m_copy()/m_copym() is changed,
depending on whether or not M_EXT is set.  If M_EXT is set, then the
buffer is *NOT* coppied, just another external reference is made and
the appropriate counter incremented.  If it is unset, then a new
buffer is allocated (M_GET) and data copied from the orignal to the
copy.  Given that it isn't a trivial issue to set or reset M_EXT,
I feel there needs to be some other control here to select whether
or not to just "make another reference" or not.

The only plausible approach would appear to be to add another arg
to m_copy() that would force it to copy all buffers, even if M_EXT
is set.  Maybe make an M_FORCECOPY that's M_COPYALL+1 ?

The nice thing to do would be to create a separate function, named
something akin to m_dup() which would not create any data buffers,
except that this doesn't appear to mesh very well with normal mbufs.

btw, the problem which makes me ask this is that if you call m_copy(),
expecting to get your own private copy of the packet data which is
able to be modified, you're in for a `rude shock'.

Comments ?

Darren