Date: Mon, 22 Oct 2007 13:31:27 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: arch@freebsd.org, "Constantine A. Murenin" <cnst@freebsd.org> Subject: Re: sensors fun.. Message-ID: <20071022133127.m6cdvrs3c4o4480c@webmail.leidinger.net> In-Reply-To: <20071019175602.GD39759@funkthat.com> References: <200710171245.36949.jhb@freebsd.org> <20071018133949.1430dlowvks8w4kg@webmail.leidinger.net> <20071019175602.GD39759@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting John-Mark Gurney <gurney_j@resnet.uoregon.edu> (from Fri, 19 Oct 2007 10:56:02 -0700): > Alexander Leidinger wrote this message on Thu, Oct 18, 2007 at 13:39 +0200: >> One level is in the kernel. It's just an export interface to transfer >> status data from the kernel to userland. The goal of this framework is >> IMO to "collect" all this data in the kernel and provide a single >> point of contact for the userland to query this in-kernel data. That's >> what the soc project was about. Let's call this kernel sensors >> framework here. > > The project may have been about that, but what was committed included > more than that (systat and sensord)... systat shows what we have in hw.sensors. It allows users to use it already now. systat takes just a peek at it and displays it. It is not supposed to be a single-system monitoring solution, it just displays some kernel values like top and ps and the rest of systat does. John mentioned some kind of abstraction layer (a lib) to hide the implementation detail of the transport interface between the kernel and the userland. That's a good idea. I don't see where it is not possible to convert systat to such an abstraction layer (a lib) when it is available. In the mean time other people can add more sensors and are able test if it works with an easy tool. For sensorsd: it's a tool to log some events to syslog, it's not a fully developed single-system monitoring tool. You want to have log traces somewhere when something goes wrong. And it doesn't make sense to me to keep the decission making process -- when is is ok to log something and when not based upon a config file -- in the kernel. This is something what can be done in userland and doesn't need kernel code. Like Poul mentioned, as much as possible shall be done in the userland. And sensorsd can also be converted to use a library to access the hw.sensors interface. Or maybe even removed, in case FreeBSD get's a single-system sensors framework which takes care about this. > It does look like you are finally understanding what we have been > talking about.. so I won't comment on the rest of it.. Sorry, but this is my point of view since a long time. That's nothing I developed just recently. I will answer to your mail where I talked about access to ISA stuff as time permits (maybe after I return from hospital in a week or two), and I try to do it in a verbose way so that the picture about Constantine's sensors framework is more clear (I hope). And what you are talking about, doesn't seem to be what Poul is talking about. For example what Poul proposes in the thread here on arch (I've only read until the messages from Friday afternoon local time, but will catch up later) needs much more "business logic" in the kernel. If he wants to to an ioctl to tell the driver the polling interval, then this exceeds the pure transport layer idea and moves a lot of infrastructure which belongs IMO into a single-system sensors framework (timers for sensors which are not event driven, trigger values for sensors which measure analogue things, ...), but not in a kernel sensors framework. I can see benefits for something what he proposes in some cases (when events need to be reported very very fast), but all those cases I can come up with where this is needed to be in the kernel instead of in the userland, involves questions like the maximum time until an event has to be reported to an application, and if/how the FreeBSD kernel is able to fulfill such requirements. If something like this is only needed in very few cases, I don't think the kernel framework should be designed around that minority. The cases I can come up with are where the monitoring is not monitoring of the system (FreeBSD PC), but of something external. Something where the purpose of the system is to take care about some (e.g., life-) critical "application/service/device/...". I think those are special situations which may need special handling of such things. Something where a generic framework (and we all know that something what is supposed to be to work in a lot of cases often trades in simplicity to use and abstraction with speed and direct access) is in the way of the very special needs of the goal at hand in such a situation. For those reasons I asked several questions to Poul here in this thread (I don't assume I know every possible use-case), unfortunately he told me he is not interested in answering me those questions. What Poul proposes contradicts the pure transport layer idea you are talking about (and I think Constantines kernel sensors framework is an implementation of such a transport layer). As you are interested in a lean and mean kernel implementation, maybe you (or someone else) can answer me the questions I directed to Poul (in case you support him regarding this part too, and in case this was not answered in arch@ already since Friday afternoon (I will catch up with the discussion on arch@ later)) to let me understand why a lot of code which would reside in userland (with e.g., Constantine's sensors framework or some other implementation) would need to move into the kernel with the architecture Poul proposes. Bye, Alexander. P.S.: When I don't answer immediately to answers or questions, it's not because I don't want to answer. I will answer when I'm back from hospital. -- Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics, Benchmarks, and Delivery dates. 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?20071022133127.m6cdvrs3c4o4480c>