From owner-cvs-all Fri Feb 14 8:50:17 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 020BF37B401; Fri, 14 Feb 2003 08:50:14 -0800 (PST) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7A0B43F85; Fri, 14 Feb 2003 08:50:13 -0800 (PST) (envelope-from bmilekic@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id h1EGoDbv052029; Fri, 14 Feb 2003 08:50:13 -0800 (PST) (envelope-from bmilekic@repoman.freebsd.org) Received: (from bmilekic@localhost) by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h1EGoDl6052028; Fri, 14 Feb 2003 08:50:13 -0800 (PST) Message-Id: <200302141650.h1EGoDl6052028@repoman.freebsd.org> From: Bosko Milekic Date: Fri, 14 Feb 2003 08:50:13 -0800 (PST) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern subr_mbuf.c subr_mchain.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 Revision Changes Path 1.37 +2 -4 src/sys/kern/subr_mbuf.c 1.12 +0 -1 src/sys/kern/subr_mchain.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message