Date: Fri, 27 Mar 2009 13:31:51 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: geom@freebsd.org Subject: Re: usage and format of kern.geom.conf* sysctl variables Message-ID: <4844.1238160711@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 27 Mar 2009 14:01:08 %2B0100." <20090327130108.GA96723@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4844.1238160711>