From owner-freebsd-arch Fri Mar 7 8:26:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B47D37B401 for ; Fri, 7 Mar 2003 08:26:47 -0800 (PST) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EBB143F85 for ; Fri, 7 Mar 2003 08:26:43 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b220.otenet.gr [212.205.244.228]) by mailsrv.otenet.gr (8.12.8/8.12.8) with ESMTP id h27GQdNJ006106 for ; Fri, 7 Mar 2003 18:26:40 +0200 (EET) Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.8/8.12.8) with ESMTP id h27GQZMI004816 for ; Fri, 7 Mar 2003 18:26:39 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.8/8.12.8/Submit) id h27Epd7w003627; Fri, 7 Mar 2003 16:51:39 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 7 Mar 2003 16:51:39 +0200 From: Giorgos Keramidas To: Hiten Pandya Cc: arch@freebsd.org Subject: Re: Using m_getcl() in network and nfs code paths Message-ID: <20030307145139.GD2094@gothmog.gr> References: <20030307004958.GA98917@unixdaemons.com> <20030306212638.A32850@xorpc.icir.org> <20030307080659.GA60937@unixdaemons.com> <20030307002525.A50491@xorpc.icir.org> <20030307092256.GA69971@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030307092256.GA69971@unixdaemons.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2003-03-07 04:22, Hiten Pandya wrote: > Luigi Rizzo (Fri, Mar 07, 2003 at 12:25:25AM -0800) wrote: > > the logic of this code > > > > m = (n > X) ? m_getcl(...) : m_get(...) > > > > The following: i have n bytes of data, give me a place large > > enough to store them. This can be either a single mbuf or an > > mbuf+cluster, depending on the size. The threshold (X) is whatever > > fits into the mbuf (which varies depending on whether or not this is > > a pkthdr mbuf, but again this is easy to tell inside m_getcl because > > you are passing the M_PKTHDR flag). > > > > Now, MINCLSIZE/MHLEN are basically the same thing, and MLEN covers > > the case for !M_PKTHDR. But my point is that the programmer should > > not bother to know which one to use and instead just let the function > > do the right thing. Fewer chances for bugs, and smaller code. > > Right. I guess it makes better sense. I will try and come up > with these changes over the weekend, or maybe even today if I > get the time. > > Cheers Luigi. Can you also convert all those (condition) ? true : false; things to (cleaner, in my opinion) if {...} else {...} pairs? It really hurts my eyes trying to read those ?: things, and writing these as: if (n > X) m_getcl(...); else m_get(...); has the added benefit that whenever one needs to fix just code of the `else' part, the diff output of the changes will be much much cleaner in the future. This is, of course, more related to style than the real architectural characteristics of the code. But I just thought I'd mention it, since I was too striken fairly fast by the same impression that Luigi mentioned in his first post. The argument of rewriting code to make things easier for possible future changes is, admittedly, a bit weak. But you can certainly forget about all this if it's too much trouble :) - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message