From owner-freebsd-geom@FreeBSD.ORG Fri Mar 27 13:31:53 2009 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CCBE1065674 for ; Fri, 27 Mar 2009 13:31:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 527ED8FC20 for ; Fri, 27 Mar 2009 13:31:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E176578CCD; Fri, 27 Mar 2009 13:31:51 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RDVpp4004845; Fri, 27 Mar 2009 13:31:51 GMT (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 14:01:08 +0100." <20090327130108.GA96723@onelab2.iet.unipi.it> Date: Fri, 27 Mar 2009 13:31:51 +0000 Message-ID: <4844.1238160711@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@freebsd.org Subject: Re: usage and format of kern.geom.conf* sysctl variables X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 13:31:54 -0000 In message <20090327130108.GA96723@onelab2.iet.unipi.it>, Luigi Rizzo writes: >QUESTION #1 > All the variables return a trailing NUL when printed, > because their handler is > > error = SYSCTL_OUT(req, sbuf_data(sb), sbuf_len(sb) + 1); > > I wonder if the trailing NUL is intentional in all cases. Yes. >QUESTION #2 > Is it reasonable to put in the variables also information > accumulated at runtime (eg. usage stats and so on), or > we should stick to pure "configuration" information ? No. Statistics are collected via the shared-memory interface which gstat(8) uses. This is much more efficient since there is no syscall overhead to update the values. >QUESTION #3 (content) > Should we limit the content of these variables to > 'configuration' info (e.g. name, topology, media sizes) or is > it reasonable to have fields for stats and other info accumulated > at runtime ? The intention is that confxml is definitive with respect to relevant configuration information. That is not the same as to say that _everything_ should be included in it. >QUESTION #4 (conftxt record separator) > It seems that the format is one line per provider, so e.g. > if a provider has to print a lot of info (e.g. an array of > numbers) it still has to put everything on one line, right ? contxt is specifically and *only* for the use of sysinstall. This use should be discontinued as soon as possible. >QUESTION #4 (conftxt format) > Any reason why conftxt is limited to DISK and MD classes ? See above. I wrote a couple of "blue print" articles about this stuff for daemonnews many years ago, I hope they still exist somewhere on the net, because they are still relevant. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.