From owner-freebsd-geom@FreeBSD.ORG Fri Mar 27 12:56:10 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 63CAD1065702; Fri, 27 Mar 2009 12:56:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 28DC98FC18; Fri, 27 Mar 2009 12:56:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 571DA73098; Fri, 27 Mar 2009 14:01:08 +0100 (CET) Date: Fri, 27 Mar 2009 14:01:08 +0100 From: Luigi Rizzo To: phk@freebsd.org, geom@freebsd.org Message-ID: <20090327130108.GA96723@onelab2.iet.unipi.it> References: <20090326110048.GA48516@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090326110048.GA48516@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Subject: 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 12:56:11 -0000 I have a few questions on the following sysctl variables, implemented in sys/geom/geom_kern.c kern.geom.conftxt kern.geom.confdot kern.geom.confxml 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, and if so, did you add it to hide the output in the default output, or because the string may contain non-low-ascii character ? (I am asking because on the console the trailing NUL is printed as an extra space; xterm output is fine). 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 ? 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 ? 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 ? QUESTION #4 (conftxt format) Any reason why conftxt is limited to DISK and MD classes ? Also, for each provider, conftxt does not print the name of the geom the provider is attached to, but only its class; this doesn't let me figure out the linkage, e.g. in the case below how do I know that ntfs/WINXP is on ad0s1 and not on, say, another disk with the same mediasize ? ... 0 DISK ad0 160041885696 512 hd 16 sc 63 1 SCHED ad0.sched. 160041885696 512 2 MBR ad0.sched.s3 113993842688 512 i 2 o 46046117888 ty 15 3 MBREXT ad0.sched.s5 113992794112 512 i 0 o 1048576 ty 7 2 MBR ad0.sched.s2 3093299200 512 i 1 o 42952818688 ty 27 2 MBR ad0.sched.s1 42952379904 512 i 0 o 32256 ty 7 1 MBR ad0s3 113993842688 512 i 2 o 46046117888 ty 15 2 MBREXT ad0s5 113992794112 512 i 0 o 1048576 ty 7 3 LABEL ntfs/DATA 113992794112 512 i 0 o 0 1 MBR ad0s2 3093299200 512 i 1 o 42952818688 ty 27 2 LABEL ntfs/RECOVERY 3093299200 512 i 0 o 0 1 MBR ad0s1 42952379904 512 i 0 o 32256 ty 7 2 LABEL ntfs/WINXP 42952379904 512 i 0 o 0 ... cheers luigi