/etc/defaults/services and /etc/services

Matthew Dillon dillon at apollo.backplane.com
Fri Feb 11 10:25:48 PST 2005


:Hi,
:
:>    Your patch looks like a good first attempt.  Here are some comments:
:
:Okay, I edited the code according to your comments; I'll make a patch
:available later the evening, this time including the carloads of man
:pages that mention /etc/services.
:
:>    want to hash the service names scanned from earlier files and skip
:>    any that are found to match in later files.
:
:I don't see why we should do this, since /etc/services is read before
:/etc/defaults/services, so if a protocol name appears in both files,
:the entry from /etc/services matches first and getservent() returns,
:ignoring all subsequent entries.

    I'm not worried about the internal use of getservent(), I'm thinking
    more of external applications using getservent() and possibly getting
    confused.  There are a couple that do.  It may or may not be a problem,
    we could probably do a first-run without the merging and not create any
    problems.

:I agree this could be done better:
:
:Now that I looked at the original code, I found it worth being
:completely rewritten...at least to get rid of all these "goto"
:statements. Furthermore, I believe it's much more elegant to read both
:files once and merge them into a memory buffer.

    Please, be my guest on the gotos.

    On the in-memory merging... well, remember that at least one of these
    files is > 70KB.  That's a pretty nasty chunk of memory to use even
    temporarily.  Hashing just the names would eat less (temporary) memory.

    Also these functions are typically used just once in a program, at
    startup.  They aren't in the critical path.  So buffering might actually
    be detrimental.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>

:This way, we could check/avoid duplicate entries while parsing the
:files, and would additionally have some basic mechanism to explicitly
:disable a service, no matter what keyword or special character it will
:be to do so; the basics would already be there.
:
:Furthermore, we could kiss those file I/O functions goodbye, since
:there would only be a small memory buffer to be "rewinded" by
:setservent(), and no need to keep the files open.
:
:Finally, I do believe a few more comments in the code would be nice.
::)
:
:So, if this sounds good to you, I'll start working.
:
:Enjoy the show
:
:--j






More information about the Submit mailing list