In message <[EMAIL PROTECTED]>, 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
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
