From owner-freebsd-hackers Fri Jul 30 15: 7:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 8CE591571E for ; Fri, 30 Jul 1999 15:07:32 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA07470; Fri, 30 Jul 1999 15:05:14 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 30 Jul 1999 15:05:14 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Matthew Dillon Cc: Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: Mentioning RFC numbers in /etc/services In-Reply-To: <199907290107.SAA65216@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Jul 1999, Matthew Dillon wrote: > :> Sheldon Hearn writes: > :> > I plan to mention in the comments for each service in /etc/services, the > :> > latest RFC describing the service. > :> > :> Good idea. > : > : Hmmmm... I'm not sure what this gets us. Wouldn't it be better to > :place this kind of information in the man page that you suggest below? As > :often as /etc/services gets read, do we really want to bloat it with > :non-functional information? > :... > :Doug > > I kinda like the idea of putting the RFC numbers in comments in > /etc/services. It makes the comments more meaningful. I still haven't heard anyone answer the two key (IMO) questions. Why is it better to have this in the file than in a man page, and how do you justify the additional cost to parse the file for every single system call that uses it? Please note that I _do_ think that the information is valuable. My only concern is that putting it IN the file has more costs than benefits. > It would be nice if we DBM'd /etc/services. Well that would definitely solve the problem of the "cost" of comments that I mention above, and it could also be handy in the sense that you could build an error-checker into the dbm'ing process. However this raises additional questions, like how to deal with the situation where the file is updated but the db is not. Thinking in mergemaster terms, I already have to special case master.passwd for this reason, and probably should special case login.conf too (just made myself a note). Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message