usage and format of kern.geom.conf* sysctl variables

[Poul-Henning Kamp]

In message <20090327130108.GA96723 at 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 at 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.