Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Nov 2007 21:57:18 +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:  <20071109215718.370a90d6@deskjail>
In-Reply-To: <200711092103.48652.qpadla@gmail.com>
References:  <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> <20071109185741.13930f0b@deskjail> <200711092103.48652.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 21:03:43 +0200):

> On Friday 09 November 2007 19:57:41 Alexander Leidinger wrote:
> > 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.
> 
> Then it's ok for me :) 
> But i think you should drop some unrealistic requirements:
> Please do not define some event-latency thresholds here. So if it's to 
> complicated to handle in kernel event triggers, just let the daemons do 
> the job. FreeBSD is not RT OS in any way.

You just expressed my opinion in another way. Poul's suggestion
triggered those thoughts, and as I already wrote, as long as we don't
have hard date which shows that we need something like this, we should
not put the polling code into the kernel. IMO we should let the
userland do the work. In my current view of the situation we just use
devctl to notify the userland about a change of a event based sensor.
For non-event based sensors the userland is responsible to poll in
suitable time intervals.

> An RFC already mentioned above show a good example of how the data could be 
> exported to another world via SNMP (you can even generate traps via BSNMPD 
> daemon), let's do not invent yet another "Group-level sensors framework". 
> I am bit sceptic of it. So as an admin i would be happy with a daemon that 
> could write some logs and trigger events, utility that could show current 
> stats and SNMP MIB that could be listed via network. This just my 
> requirements for sensors framework as a black box :) 

The userland library we have in mind would allow to define a config for
the sensors in a central place for all tools which make use of it. One
tool which could make use of it would be bsnmpd. It could contain a
generic plugin which queries the userland sensors library and populate
a suitable MIB with all the sensors the library provides. The userland
library could also be used by systat to show the current stats. For the
events triggering (only for event based sensors) devd could be used in
the current model I wrote about. And regarding the logging of some
sensor data, there's also no problem (also using the library).

In fact for all the usage scenarios you talked about (except for
bsnmpd) exists code produced in a Google Sumemr of Code project which
does just this for kernel sensors. What we do here in this thread is to
evaluate the architecture of some kind of sensors framework we want to
have and if the existing code meets our architectural requirements (or
parts of it). If it meets our requirements, the next logical step would
be to investigate the code if it fulfills our quality requirements, or
if there need to be some changes to it.

Bye,
Alexander.

-- 
VICARIOUSLY experience some reason to LIVE!!
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?20071109215718.370a90d6>