In message <37a3e203.de0fe...@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 hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
