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 =20 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 =20 already now. systat takes just a peek at it and displays it. It is not =20 supposed to be a single-system monitoring solution, it just displays =20 some kernel values like top and ps and the rest of systat does. John =20 mentioned some kind of abstraction layer (a lib) to hide the =20 implementation detail of the transport interface between the kernel =20 and the userland. That's a good idea. I don't see where it is not =20 possible to convert systat to such an abstraction layer (a lib) when =20 it is available. In the mean time other people can add more sensors =20 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 =20 fully developed single-system monitoring tool. You want to have log =20 traces somewhere when something goes wrong. And it doesn't make sense =20 to me to keep the decission making process -- when is is ok to log =20 something and when not based upon a config file -- in the kernel. This =20 is something what can be done in userland and doesn't need kernel =20 code. Like Poul mentioned, as much as possible shall be done in the =20 userland. And sensorsd can also be converted to use a library to =20 access the hw.sensors interface. Or maybe even removed, in case =20 FreeBSD get's a single-system sensors framework which takes care about =20 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 =20 I developed just recently. I will answer to your mail where I talked =20 about access to ISA stuff as time permits (maybe after I return from =20 hospital in a week or two), and I try to do it in a verbose way so =20 that the picture about Constantine's sensors framework is more clear =20 (I hope). And what you are talking about, doesn't seem to be what Poul is =20 talking about. For example what Poul proposes in the thread here on =20 arch (I've only read until the messages from Friday afternoon local =20 time, but will catch up later) needs much more "business logic" in the =20 kernel. If he wants to to an ioctl to tell the driver the polling =20 interval, then this exceeds the pure transport layer idea and moves a =20 lot of infrastructure which belongs IMO into a single-system sensors =20 framework (timers for sensors which are not event driven, trigger =20 values for sensors which measure analogue things, ...), but not in a =20 kernel sensors framework. I can see benefits for something what he =20 proposes in some cases (when events need to be reported very very =20 fast), but all those cases I can come up with where this is needed to =20 be in the kernel instead of in the userland, involves questions like =20 the maximum time until an event has to be reported to an application, =20 and if/how the FreeBSD kernel is able to fulfill such requirements. If =20 something like this is only needed in very few cases, I don't think =20 the kernel framework should be designed around that minority. The =20 cases I can come up with are where the monitoring is not monitoring of =20 the system (FreeBSD PC), but of something external. Something where =20 the purpose of the system is to take care about some (e.g., life-) =20 critical "application/service/device/...". I think those are special =20 situations which may need special handling of such things. Something =20 where a generic framework (and we all know that something what is =20 supposed to be to work in a lot of cases often trades in simplicity to =20 use and abstraction with speed and direct access) is in the way of the =20 very special needs of the goal at hand in such a situation. For those =20 reasons I asked several questions to Poul here in this thread (I don't =20 assume I know every possible use-case), unfortunately he told me he is =20 not interested in answering me those questions. What Poul proposes =20 contradicts the pure transport layer idea you are talking about (and I =20 think Constantines kernel sensors framework is an implementation of =20 such a transport layer). As you are interested in a lean and mean =20 kernel implementation, maybe you (or someone else) can answer me the =20 questions I directed to Poul (in case you support him regarding this =20 part too, and in case this was not answered in arch@ already since =20 Friday afternoon (I will catch up with the discussion on arch@ later)) =20 to let me understand why a lot of code which would reside in userland =20 (with e.g., Constantine's sensors framework or some other =20 implementation) would need to move into the kernel with the =20 architecture Poul proposes. Bye, Alexander. P.S.: When I don't answer immediately to answers or questions, it's =20 not because I don't want to answer. I will answer when I'm back from =20 hospital. --=20 Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics, Benchmarks, and Delivery dates. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071022133127.m6cdvrs3c4o4480c>