From owner-cvs-src@FreeBSD.ORG Sun May 28 13:04:15 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 387B816BDD6; Sun, 28 May 2006 13:04:15 +0000 (UTC) (envelope-from netchild@FreeBSD.org) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ECDD43D82; Sun, 28 May 2006 13:03:57 +0000 (GMT) (envelope-from netchild@FreeBSD.org) Received: from Andro-Beta.Leidinger.net (p54A5F984.dip.t-dialin.net [84.165.249.132]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.4/8.13.4) with ESMTP id k4SD3W9N077072; Sun, 28 May 2006 15:03:33 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k4SD3nsJ002299; Sun, 28 May 2006 15:03:50 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Date: Sun, 28 May 2006 15:03:53 +0200 From: Alexander Leidinger To: gnn@FreeBSD.org Message-ID: <20060528150353.094da5b8@Magellan.Leidinger.net> In-Reply-To: References: <20060526204457.3e545e4f@Magellan.Leidinger.net> <11534.1148678206@critter.freebsd.dk> <20060527104539.1f4c0738@Magellan.Leidinger.net> <20060527200440.G79162@fledge.watson.org> Organization: FreeBSD X-Mailer: Sylpheed-Claws 2.2.0 (GTK+ 2.8.17; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=MP_bZOgGMsfDDlwEw7O_ynqdnU X-Virus-Scanned: by amavisd-new Cc: cvs-src@FreeBSD.org, Poul-Henning Kamp , src-committers@FreeBSD.org, Robert Watson , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/doc/subsys Dependencies Doxyfile-cam Doxyfile-crypto Doxyfile-dev_pci Doxyfile-dev_sound Doxyfile-dev_usb Doxyfile-geom Doxyfile-i4b Doxyfile-kern Doxyfile-libkern Doxyfile-linux Doxyfile-net80211 ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2006 13:04:26 -0000 --MP_bZOgGMsfDDlwEw7O_ynqdnU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Quoting gnn@FreeBSD.org (Sun, 28 May 2006 11:12:19 +0900): > Am I allowed to call this a tempest in a teacup? > > There, I just have. > > While I think that there have been some very good points made both > ways, I believe that since the documentation will be generated only by > people who are using the system, and will not appear on line, or in a > manual, that we do not need to worry about this. It is, IMHO, easier As Scott already said: it doesn't matter if it is made public or not. "The bad guys"(TM) will use non-public functions regardless. And since generating all docs isn't fast (I need several hours to generate the current ones on my Athlon XP 2200+), it would be nice to have them online somewhere. I already have a disclaimer file (attached), I just wait for the "when this text is included it's ok for me" from those people which worry about the misuse of the docs. > to go through and mark things up AFTER we have them visible and so > visibility should be the first goal. Since there is, as far as I > know, no other or better tool for this job I suggest we go with what > we have and begin to mark things correctly now. Having everything by > default internal, IMHO, leaves us just where we were before, lots of > twisty little APIs all undocumented. > > My $0.02. I agree. Bye, Alexander. -- Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 --MP_bZOgGMsfDDlwEw7O_ynqdnU Content-Type: text/plain; name=notreviewed.dox Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename=notreviewed.dox /** @mainpage * IMPORTANT: This API documentation may contain both functions which * are public and functions that are for internal use only. Since we have not * reviewed every part of the documentation yet, some internal functions * are not marked as such. Until we finish reviewing the API documentation * and add appropriate comments to functions which are only for internal use, * you should take this into account. In case you want to use a function of * this kernel subsystem in another kernel subsystem you should search for * precedence of use outside this subsystem. If the function is not used * outside this subsystem you should ask on the mailinglists about it, else * you risk breaking something. */ --MP_bZOgGMsfDDlwEw7O_ynqdnU--