From owner-cvs-all Sun Jan 10 03:21:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA05630 for cvs-all-outgoing; Sun, 10 Jan 1999 03:21:09 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from firewall.reed.wattle.id.au (darren2.lnk.telstra.net [139.130.53.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA05619 for ; Sun, 10 Jan 1999 03:20:52 -0800 (PST) (envelope-from darrenr@reed.wattle.id.au) Received: (from root@localhost) by firewall.reed.wattle.id.au (8.9.1/8.8.7) id LAA13309; Sun, 10 Jan 1999 11:20:17 GMT Received: from avalon.reed.wattle.id.au(192.168.1.1) by firewall.reed.wattle.id.au via smap (V1.3) id sma013307; Sun Jan 10 11:20:12 1999 Received: from percival.reed.wattle.id.au. (percival.reed.wattle.id.au [192.168.1.5]) by avalon.reed.wattle.id.au (8.9.0.Beta3/8.9.0.Beta3) with SMTP id WAA15560; Sun, 10 Jan 1999 22:20:11 +1100 (EST) From: Darren Reed Message-Id: <199901101120.WAA15560@avalon.reed.wattle.id.au> Subject: Re: sysctl descriptions To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Sun, 10 Jan 1999 22:20:10 +1100 (EST) Cc: phk@critter.freebsd.dk, des@flood.ping.uio.no, committers@FreeBSD.ORG In-Reply-To: <50085.915954825@zippy.cdrom.com> from "Jordan K. Hubbard" at Jan 9, 99 11:53:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In some email I received from Jordan K. Hubbard, sie wrote: > > Actually, there is a legitimate syncronization issue to be dealt with > here. If I have a sysctl implemented in one area of the code with a > doc string that describes it, I'm going to be more inclined to stick > it in the macro definition or something itself so that I have doc > string and associated sysctl code together. If I have to go remember > to edit a file somewhere as well, I'm going to forget just as > developers have been forgetting such extraneous details for years and > the problem is acute enough that entire programming paradigms > (tangle/weave) have been evolved in an effort to deal with the > problem. I'd sooner have a larger kernel if it meant that my > doc strings had a better chance of being actually *correct*. :) If you have such problems then the tools you are using to generate code for your object are not suitable to the task at hand. There is a plethora of extremely useful text manipulation tools ("perl" for one) which could easily automate any such documentation task if it were merely based on the contents of a .c file. As I'm not familiar with the KLD issue, I cannot say what would and wouldn't be a good way to resolve the problem. If it were applied to KLM's, then my response would be to have the "modload process" involve more than just "modload foo.o". It might be that a wrapping program or script is needed (modload already supports something similar with the -e command line option). If the interface is truely lacking in a way to support this feature then perhaps the interface needs to change. I'm not trying to say that the descriptions shouldn't be there, but at least try to be smart about considering alternatives and the work involved. We should be at least trying to move out of the stone age of programming now (it is, however, hard when that is what you're used to). Personally, I view the sysctl description code as done by DES as the "easy solution". It's more than likely what most people would do if they had the same problem to solve. I don't know whether I would go on to say that this is the "correct" solution for "this problem" (but then people may not be at all interested in the "correct" solution). Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message