Date: Wed, 13 Jun 2001 04:54:16 +0900 (JST) From: Hajimu UMEMOTO <ume@mahoroba.org> To: bmilekic@technokratis.com Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_output.c Message-ID: <20010613.045416.125862267.ume@mahoroba.org> In-Reply-To: <20010611152724.A33314@technokratis.com> References: <200106111838.f5BIcCJ05392@freefall.freebsd.org> <20010611152724.A33314@technokratis.com>
index | next in thread | previous in thread | raw e-mail
>>>>> On Mon, 11 Jun 2001 15:27:24 -0400
>>>>> Bosko Milekic <bmilekic@technokratis.com> said:
bmilekic> The commit to sys/sys/mbuf.h severely bloated the mbstat structure.
bmilekic> Quads were added to apparently account for trivial things, such as `number
bmilekic> of times pullup was done,' and so on. There are several problems with this.
These quads were wrongly added during KAME merge. I nuked it already.
Sorry for bothering you.
bmilekic> Furthermore, the other change to sys/sys/mbuf.h and friends had to do
bmilekic> with moving a check from m_free() to the more general MFREE() macro. The check
bmilekic> itself bloats the macro (increasing the size of the kernel). Normally, I
bmilekic> wouldn't object but from the surrounding comments it appears that it is possible
bmilekic> to fix the problem _properly_. The comment claims that the check is there
bmilekic> because there is still code that doesn't call M_PULLUP() properly. As opposed
bmilekic> to bloating the allocation/free code with the bogus check, how difficult would
bmilekic> it be to ensure that M_PULLUP() is called properly?
Since KAME code is writtenin in this form, restoring check from
MFREE() to m_free() may have risk.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010613.045416.125862267.ume>