> > On Fri, Apr 20, 2007 at 01:54:33PM -0400, Greg Troxel wrote:
> > > Pavel Cahyna <pavel@netbsd.org> writes:
> > > 
> > > > On Fri, Apr 20, 2007 at 01:40:16PM -0400, Greg Troxel wrote:
> > > >>   What I've missed there was a description of "guaranteed contiguous
> > > >>   data". The problem is that one function can make part of the mbuf chanin
> > > >>   contiguous (like m_pulldown or one of the new functions), but a
> > > >>   subsequent call can fragment the chain again. To prevent this, I have
> > > >>   introduced the notion of "guaranteed contiguous data". If a function
> > > >>   makes a range of a mbuf chain contiguous, it also marks it as a
> > > >>   guaranteed contiguous region and subsequent calls to mbuf rearranging
> > > >>   functions must keep it contiguous.
> > > >> 
> > > >> If it's not safe for a caller to assume it's still true, then the word
> > > >> guaranteed shouldn't be used.  What you're describing is more like an
> > > >> efficiency hint.  This also seems complicated, and if a caller can't
> > > >> safely omit checks, I'm not sure how much is gained.
> > > >
> > > > The purpose is exactly to be able to omit checks.
> > > 
> > > Then you have to specify very carefully under what circumstances the
> > > checks can be omitted; you said that the "guarantee" couldn't always be
> > > honored.
> > 
> > Yes, you should not call m_pulldown... and if there are more restrictions
> > like that, they should be of course documented.
> > 
> > Pavel
> 
> is it worth to have such complicate semantics?
> 
> YAMAMOTO Takashi

can you give me an example where the "guaranteed contiguous data" notion
is actually needed?

YAMAMOTO Takashi