Date: Fri, 9 Nov 2007 18:57:41 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: qpadla@gmail.com Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) Message-ID: <20071109185741.13930f0b@deskjail> In-Reply-To: <200711091851.19445.qpadla@gmail.com> References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Nikolay Pavlov <qpadla@gmail.com> (Fri, 9 Nov 2007 18:51:10 +0200): > On Friday 09 November 2007 13:44:21 Alexander Leidinger wrote: > > Robert thinks that sysctl MIBs offer "a more semantically rich and, to > > be honest, better defined way of interacting with live subsystems than > > device files do in a generic sense". Nobody objected to this opinion or > > provided reasons why a fd based approach is better than a sysctl MIB > > based approach. Ricardo Nabinger Sanchez points out > > http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs). > > I think a MIB approach is much more usefull between "Single-system sensors > framework" and "Group-level sensors framework" and a good example here is > a SNMP(the general usage example of the MIB defined in rfc3433). I am not > a kernel developer and don't know whether it's a good for pass the data or > not, but as experienced administrator should mansion that sysctl mib's is > expected (IMHO) to be used as a configuration interface to define a kernel > and system behavior. It's much more easy to use userland utilities such as We have a lot of read only sysctls, so it's de-facto not only a configuration interface, but also a status description interface already. And if you use top or ps, you already use the sysctl framework to get the information about the processes. Both utilities use libkvm, which is the official userland interface to access this information. The libkvm uses the internal interface via sysctls to get this information. So we already have precedence of the use of sysctl for such status data. > vmstat, systat, netstat, sockstat than listing some stats and data via > sysctl. Also i suspect that such complex and rich thing as sensors You are not supposed to list stats and data via sysctl (the kernel level sensors framework) as an administrator. You are supposed to use the userland tools (the single-system sensors framework tools) to query this data. Listing the sensors in systat would be one way of accessing this information, and people already have though about this (this thread is triggered by Google Summer of Code 2007 work where the sensors are already displayed in systat). If you "by accident" know how to get the sensor information the "inofficial" way, nobody prevents you to do it (like nobody prevents you to get the same information as top/ps gets via sysctl), but then you are supposed to not moan if we change the way we export this data. > framework often would be a subject to various changes and extensions, so i > vote to hide kernel part as much as possible. This was addressed further down in the text (the part which you didn't quote here). The official user interface to the sensors from userland would be the userland library. As we are an open source OS, we can not hide something, we can only declare something as an official interface, or an internal interface. sysctl would allow to export the data in an hierarchical and unified way. sysctl is a well tested and working interface in FreeBSD to export data from the kernel to the userland. If or if not there are much changes and extensions in an incompatible way, can not be determined in such a high level architectural discussion. To be able to talk about this, we have to got more towards the implementation direction. But anyway, the userland access library we envision so far is supposed to handle this gracefully. The implicit question we answered here is, if we invent a new interface or augment an existing and well tested interface with some meta information in a subtree. So far it looks we want to use existing interfaces (a sysctl subtree for the data and devctl for notifications). What such an hierarchical and MIB like interface allows is, that you can get the notification "event sensor X switched to a critical value" and directly poll the value in an easy way. If, for example, you want to produce something similar via a pseudo-filesystem, you have to actually write a filesystem. This is a more complex task to get right than to use the functions in the kernel to handle sysctls. It also involves more processing in the kernel (mounting, VFS interaction, ...). With procfs we learned that a filesystem for something like this is hard to get right. After switching from procfs to sysctl's to gather data for top/ps/..., we noticed that it is more easy to get right via sysctl's, and that sysctl's are a good interface to export such data from the kernel. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071109185741.13930f0b>