Skip site navigation (1)Skip section navigation (2) 
Date:      Fri, 27 Mar 2009 14:01:08 +0100
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        phk@freebsd.org, geom@freebsd.org
Subject:   usage and format of kern.geom.conf* sysctl variables
Message-ID:  <20090327130108.GA96723@onelab2.iet.unipi.it>
In-Reply-To: <20090326110048.GA48516@onelab2.iet.unipi.it>
References:  <20090326110048.GA48516@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help 
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

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090327130108.GA96723>