Date: Thu, 18 Oct 2007 13:39:49 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org, "Constantine A. Murenin" <cnst@freebsd.org> Subject: Re: sensors fun.. Message-ID: <20071018133949.1430dlowvks8w4kg@webmail.leidinger.net> In-Reply-To: <200710171245.36949.jhb@freebsd.org> References: <200710171245.36949.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting John Baldwin <jhb@freebsd.org> (from Wed, 17 Oct 2007 12:45:36 -0400= ): Without commenting on specific parts of what you wrote, I think we =20 need to clarify something before we proceed. > Other things that might be nice: > > - IWBN to have a userland interface to sensors. For example, if nothing e= lse Here's what I wrote to Julian (with minor modifications) this morning, =20 before I've seen your mail here on arch. I see several levels of stuff which can be named "sensors framework" here. One level is in the kernel. It's just an export interface to transfer =20 status data from the kernel to userland. The goal of this framework is =20 IMO to "collect" all this data in the kernel and provide a single =20 point of contact for the userland to query this in-kernel data. That's =20 what the soc project was about. Let's call this kernel sensors =20 framework here. Then there's something in the userland, what can also be named =20 "sensors framework". This part would be responsible to be a single =20 point of contact to query the status data of the entire system. This =20 userland part would be responsible to collect data which is exported =20 from the kernel, and to collect data from userland stuff. It would =20 provide an interface to be able to query the in-machine data (some =20 people may say SNMP can be used for this). Let's call this =20 single-system sensors framework here. And then there's something in the network what can be named "sensors =20 framework". This part would be responsible to collect sensor data in =20 the entire (sub-)network and provide an interface to query the data =20 from the entire (sub-)network (an example can be nagios or some =20 commercial offering). Let's call this group-level sensors framework =20 for now. The term "sensor data" may by ambiguous too. When I talk about sensor =20 data, this can be some data from a device, like =20 temperature/voltage/humidity/tv channel/ rotation speed/pressure =20 level/fill level/coordinates/whatever (what we want to include of this =20 stuff or not I don't talk about, e.g., ATM I don't see a need to =20 provide the TV channel via the sensors framework). Sensor data can =20 also be the status of a subsystem in the kernel, some database related =20 things in userland, the hitrate per second of a webserver, or whatever. All (more or less) of those things may in the end need to arrive in =20 the group-level sensors framework. Before they arrive there, they =20 ideally arrive in the single-system sensors framework (reduces probing =20 complexity and the amount of work of the person who has to configure =20 the group-level sensors framework). And parts of this stuff was =20 collected from the kernel sensors framework by the single-system =20 sensors framework. The group-level sensors framework doesn't belong into FreeBSD IMO. For =20 the single-system sensors framework I have no strong opinion (and with =20 bsnmp we may have some sort of this already which just needs to be a =20 little bit extend (MIBs), but this depends upon your needs and =20 expectations). What I would like to know is where you see problems with the above =20 description and how your proposal fits into this description (if you =20 don't see major flaws in the description). To me it looks like your proposal spans more than one of the above =20 described layers in one package. It seems you describe what I call =20 single-system sensors framework above. It looks like you want to have =20 this with parts of it in the kernel. I don't think this is a good idea =20 as I don't think userland data should be feed into the kernel. Could =20 you please describe where you see benefits of your architecture =20 compared to the description I provided above? Bye, Alexander. --=20 BOFH excuse #266: All of the packets are empty 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?20071018133949.1430dlowvks8w4kg>