Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Feb 2003 11:55:37 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Bosko Milekic <bmilekic@FreeBSD.org>
Cc:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern subr_mbuf.c subr_mchain.c
Message-ID:  <20030214115537.B54113@unixdaemons.com>
In-Reply-To: <200302141650.h1EGoDl6052028@repoman.freebsd.org>; from bmilekic@FreeBSD.org on Fri, Feb 14, 2003 at 08:50:13AM -0800
References:  <200302141650.h1EGoDl6052028@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, Feb 14, 2003 at 08:50:13AM -0800, Bosko Milekic wrote:
> bmilekic    2003/02/14 08:50:13 PST
> 
>   Modified files:
>     sys/kern             subr_mbuf.c subr_mchain.c 
>   Log:
>   Make m_getm() always return the top of the newly allocated chain, as
>   opposed to returning the top of the old chain when there was one and
>   the top of the newly allocated chain if there was no old chain.
>   
>   Actually, it should be noted that prior to this fix, although the
>   comment above m_getm() advertised that m_getm() would return the
>   top of the old chain (if an old chain was being passed in) it
>   actually [wrongly] was returning the tail mbuf in the old chain
>   instead.  This is a bug but since the one use of m_getm() in
>   the tree luckily did not depend on the behavior, it happened
>   to work out without notice.
>   
>   Harti Brandt pointed out that the advertised behavior was actually
>   not the real behavior and so this change makes m_getm() ALWAYS
>   return the newly allocated chain (and fixes the comment).  This
>   is less confusing and is the best course of action as then the
>   caller is always able to have both a reference to the top of
>   the original chain (because it's passing it in in the call) and
>   a reference to the newly attached chain.  Although the API is
>   slightly modified, I don't think that any third-party code uses
>   m_getm() and if it does, it surely can't be working properly
>   because the old behavior was bogus.
>   
>   API bug pointed out by: Harti Brandt <brandt@fokus.fraunhofer.de>

  P.S.: Harti Brandt is actually a committer, so:

  Pointed out by: harti

  Sorry about that. :-)

>   Revision  Changes    Path
>   1.37      +2 -4      src/sys/kern/subr_mbuf.c
>   1.12      +0 -1      src/sys/kern/subr_mchain.c

-- 
Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org

"If we open a quarrel between the past and the present, we shall
 find that we have lost the future."

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-src" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030214115537.B54113>