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>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010613.045416.125862267.ume>