From owner-freebsd-hackers Sat Jul 31 23:19:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw00.execpc.com (mailgw00.execpc.com [169.207.1.78]) by hub.freebsd.org (Postfix) with ESMTP id 4E63F15011 for ; Sat, 31 Jul 1999 23:19:39 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net (kronos-1-145.mdm.mkt.execpc.com [169.207.86.19]) by mailgw00.execpc.com (8.9.1) id BAA17138; Sun, 1 Aug 1999 01:19:10 -0500 Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id 874C5135; Sun, 1 Aug 1999 01:19:37 -0500 (CDT) To: Doug Cc: Sheldon Hearn , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-reply-to: Your message of "Sat, 31 Jul 1999 22:58:27 PDT." <37A3E203.DE0FE656@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Aug 1999 01:19:37 -0500 From: Jon Hamilton Message-Id: <19990801061937.874C5135@woodstock.monkey.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37A3E203.DE0FE656@gorean.org>, Doug wrote: } Sheldon Hearn wrote: } > } > On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote: } > } > > I still haven't heard anyone answer the two key (IMO) questions. } > } > Your questions are easier answered in reverse order: } > } > > and how do you justify the additional cost to parse the file for every } > > single system call that uses it? } > } > The information is part of the comments within the file. The cost is in } > disk space, and it's cheaper than fleabites. } } Nowhere did I mention disk space. I agree that if that were the only is } sue } I wouldn't be raising the objection. } } > > Why is it better to have this in the file than in a man page, } > } > Since it costs nothing to have it in /etc/services, why not leave it } > there along with the information with which it's associated? The } > alternative is to have a manpage that contains most of the information } > in /etc/services! } } And why is that bad? Since when is redundancy in the documentation a } problem? Like you said, disk is cheap. } } > > My only concern is that putting it IN the file has more costs than } > > benefits. } > } > What am I missing here, that I don't see a cost? What software scans the } > lines in /etc/services beyond the comment delimiter, other than null } > terminator searches? } } So, how many comments are you going to add? Let's say the total parsing } cost to the system for all of your additions is X. X is probably a pretty } small number, I'm not arguing that point at all. Now multiply X times every } packet on a highly loaded server, because that's how many times ipfw is } going to need to parse the file (roughly). No. ipfw deals with /etc/services only at startup time (any other behavior on its part would be ridiculous). } My point is simply that the information is valuable, but it belongs in } a } man page. There is no reason to add a good deal of non-functional } information to a file that is used by so many parts of the system. I think you're overestimating the cost by a considerable amount. I'm not saying that the cost is zero, but I am saying that it's close enough that the value of having the information *right there* outweighs the cost. Can you demonstrate a realistic scenario in which multiplying the volume of comments in /etc/services by, say, 10x results in a perceptible performance hit? -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message