Date: Sat, 21 Sep 2002 11:01:56 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Darren Reed <darrenr@reed.wattle.id.au> Cc: John Baldwin <jhb@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <37234.1032598916@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 21 Sep 2002 18:51:43 %2B1000." <200209210851.SAA28535@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200209210851.SAA28535@avalon.reed.wattle.id.au>, Darren Reed writes : >I don't dispute that there should be a m_length(), however, I do not >agree it should be implemented the way it currently is - also finding >the last mbuf. There is a clear majority of cases which call m_length() >with last == NULL, all of which are penalised in having to do a loop >through all of the mbuf's rather than extracting m_pkthdr.len when able >to do so. Darren, You don't seem to understand that this function is (should only be) used in cases where m_pkthdr.len cannot be used and that the only possible way to find the length in those cases is to traverse the chain. Once this fact registers with you, I pressume I can expect you to stop proposing and committing patches which are wrong in theory and wrong in practice. And presumably: we can bury this silly thread. If you feel it is important to be able to use m_pkthdr.len in all cases, feel free to change the code which calls m_length() to be able to do this instead of calling m_length(). Please keep me out of the loop if you decide to do so. As for you reading all commit messages or not, that's your choice. I think it would be prudent for you to at least examine "recent history" for code you're about to stomp on and testing your commits are always a good idea, even when you think nothing can go wrong. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?37234.1032598916>