usage and format of kern.geom.conf* sysctl variables
phk at phk.freebsd.dk
Fri Mar 27 06:31:54 PDT 2009
In message <20090327130108.GA96723 at onelab2.iet.unipi.it>, Luigi Rizzo writes:
> 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.
> 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 ?
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.
More information about the freebsd-geom