From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 08:12:17 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4906216A41F; Mon, 29 Aug 2005 08:12:17 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7B643D49; Mon, 29 Aug 2005 08:12:16 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7T8C5o4091247; Mon, 29 Aug 2005 12:12:05 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Mon, 29 Aug 2005 12:16:01 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Doug Barton In-Reply-To: <43123F3B.8070002@FreeBSD.org> Message-ID: <20050829115740.N5409@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Jacques Vidrine , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, Brooks Davis Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 08:12:17 -0000 Hi, Doug! > I'm not sure what guidelines were given to you when you started the project, > but in reviewing your work the first thing I noticed was that you are not > following the guidelines in the style(9) man page. You should read that page, > and spend an afternoon reformatting your code to fit what is described there. > The most common error you've made is not following the 80 column rule, which > hopefully should be easily fixed. While one could argue with the specific > items in that page, and quite possibly be right, the idea of having a style > guideline is more to have a common format that we can all work towards than > to have a perfect format that we can all agree on. By reformatting your code > to fit this guideline you will greatly increase the chances that it will be > welcomed into the tree with open arms. > > The other style area that you should look at is your man pages. If you look > in /usr/share/examples/mdoc you will find the FreeBSD style guidelines for > man pages. The line wrapping issue comes into play here as well. We generally > don't go past column 60 in man pages, since that reduces CVS repo churn for > corrections down the road. Also, any time you have a full stop (period) at > the end of a sentence, you should start a new line. I think that you are also > using some macros that I'm not familiar with, although I'm not an mdoc > expert. Thank you very much for your suggestions - I'll reformat the code and man files. I've seemed to forget about style(9) in some places :( > > The other area that I'm interested in is how you plan to have cached interact > with DNS lookups, /etc/hosts, named, etc. If there was a project plan posted > somewhere on this already and I missed it, please accept my apologies, and > send along a reference. If not, I'm very interested to hear what your plans > are. > There is some information in my project's description here: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails The "Integrating nsswitch and caching" describes the way that I use to make cached work. It can actually interact with any nsswitch database. All we need is to supply the special structure (in patches it is usually called "cache_info") with 3 functions pointers (*_id_func, *_marshal_func, *_unmarshal_func). These functions are used by nsdispatch during the caching of sccessful results. id_func identifies the key - the unique identifier, which will identify the data in the cache. And marshal_func/unmarshal_func pack/unpack data into/from the (char *)buffer. So almost all data, that go through nsdispatch calls, can be cached. And "struct hostent" and "struct addrinfo" are no exceptions to this rule. I already have the patch with *_id_func, *_marshal and *_unmarshal_func implemented for the "hosts" nsswitch database. I'll send it to the list along with the corrected version of the cached a bit later (in about 12 hours). P.S. the patched version of nsdispatch uses the functions that are implemented in nscache.c and nscachedcli.c files (they are present in the patch). With best regards, Michael