Date: Thu, 12 Jul 2007 08:02:10 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Rui Paulo <rpaulo@fnop.net>, Robert, Shteryana Shopova <syrinx@FreeBSD.org>, "Constantine A. Murenin" <cnst@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Watson <rwatson@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <20070712080210.j1gquzf3koogssso@webmail.leidinger.net> In-Reply-To: <20070711185718.GH1221@funkthat.com> References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711185718.GH1221@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting John-Mark Gurney <gurney_j@resnet.uoregon.edu> (from Wed, 11 Jul 2007 11:57:19 -0700): > Alexander Leidinger wrote this message on Wed, Jul 11, 2007 at 19:51 +0200: >> Quoting "Poul-Henning Kamp" <phk@phk.freebsd.dk> (Wed, 11 Jul 2007 >> 17:33:51 +0000): >> > There is no benefit from having it in the kernel. >> >> You need to get some information out of the kernel somehow (you cut >> this part of my mail). And as far as I understand the high level >> description (presentation in the net) of this framework, this does this >> in an unified way. Do you propose to get the information out of the >> kernel in a non-uniform way? > > No you don't. The kernel is just another "transport" layer so to say.. > > We are proposing a unified way via a userland front end... The userland Nothing prevents you to do that. I just say that Constantine focuses on getting data out of the kernel (as far as I understand his project). The userland front end you propose needs also some kernel data. How do you want to get this kernel data to userland? I'm repeating me here. I already asked this to phk and he cut this part away in his answers. Do you want to extend each _existing_ kernel driver which is able to provide some interesting data (RAID status, HD status, ACPI battery status, ... you can even export some or all process info with it) on your own via hand-rolled code each time? I don't want that. I would like to prefer an unified way which is able to get 80-95% of the interesting data out of the kernel in a sane way (it's like asking if we should integrate each NIC driver into the network stack, or if we should design an unified interface which each NIC has to comply to; I think it is also similar to the mixer interface on soundcards, most of the cards use the unified mixer interface to provide you the possibility to change the volume of several channels). For the remaining 5-20% which don't fit into an unified interface in a sane way we can extend existing drivers by hand. The userland front end you propose then can be configured with a simple config file for the unified way and with some plugins or whatever for the remaining 5-20% stuff. For me Constantin's project is about providing a transport interface of in-kernel sensor data from the kernel to userland. This can be used in a lot of ways. Maybe hand it over to another transport layer to export it to another system (SNMP comes to mind), or just look at it via sysctl, or use a simple top-like display, or feed it to MRTG/nagios/whatever in some way, or write a super mega sensor front end which not only takes the kernel data but also some more data (you could see nagios as such a front end, if you want). As another step you could extend Constantin's framework with a connection to the kevent subsystem, so that interesting stuff provides notification events. For example for continuous sensors (voltage, temperature) you could register an event handler for a temperature threshold which triggers at crossing. > library knows and can adapt to different ways of extracting the data.. > If you hard code the kernel interface, when someone comes along and > wants to write a complicated sensor in userland, he will then need to > hack a "kernel frontend" to take his userland generated data, shove it > into the kernel, just for another userland app to pull the data out.. No. The kernel is not supposed to handle all sensor data. The kernel is only supposed to provide existing in-kernel sensor data to userland. Maybe it also needs to provide some (more) meta data about the sensor data to userland. So before you all repeat here saying that this project should be done differently, please tell us how you want to get interesting sensor data from existing kernel stuff out of the kernel without the need of a high privilege userland process. In case you want to augment existing drivers with some way to export this data, please also describe how you approach is different from what Constantine is doing ATM. Bye, Alexander. -- A day without sunshine is like night. 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?20070712080210.j1gquzf3koogssso>