Re: sensors fun..

Quoting John Baldwin <jhb@xxxxxxxxxxx> (from Wed, 17 Oct 2007 12:45:36 -0400):

Without commenting on specific parts of what you wrote, I think we 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 else

Here's what I wrote to Julian (with minor modifications) this morning, 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 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.

Then there's something in the userland, what can also be named "sensors framework". This part would be responsible to be a single point of contact to query the status data of the entire system. This userland part would be responsible to collect data which is exported from the kernel, and to collect data from userland stuff. It would provide an interface to be able to query the in-machine data (some people may say SNMP can be used for this). Let's call this single-system sensors framework here.

And then there's something in the network what can be named "sensors framework". This part would be responsible to collect sensor data in the entire (sub-)network and provide an interface to query the data from the entire (sub-)network (an example can be nagios or some commercial offering). Let's call this group-level sensors framework for now.

The term "sensor data" may by ambiguous too. When I talk about sensor data, this can be some data from a device, like temperature/voltage/humidity/tv channel/ rotation speed/pressure level/fill level/coordinates/whatever (what we want to include of this stuff or not I don't talk about, e.g., ATM I don't see a need to provide the TV channel via the sensors framework). Sensor data can also be the status of a subsystem in the kernel, some database related 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 the group-level sensors framework. Before they arrive there, they ideally arrive in the single-system sensors framework (reduces probing complexity and the amount of work of the person who has to configure the group-level sensors framework). And parts of this stuff was collected from the kernel sensors framework by the single-system sensors framework.

The group-level sensors framework doesn't belong into FreeBSD IMO. For the single-system sensors framework I have no strong opinion (and with bsnmp we may have some sort of this already which just needs to be a little bit extend (MIBs), but this depends upon your needs and expectations).



What I would like to know is where you see problems with the above description and how your proposal fits into this description (if you don't see major flaws in the description).

To me it looks like your proposal spans more than one of the above described layers in one package. It seems you describe what I call single-system sensors framework above. It looks like you want to have this with parts of it in the kernel. I don't think this is a good idea as I don't think userland data should be feed into the kernel. Could you please describe where you see benefits of your architecture compared to the description I provided above?

Bye,
Alexander.

--
BOFH excuse #266:

All of the packets are empty

http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensor
    ... rights than using the userland parts of the sensors framework. ... but I have learned that the kernel should never be a dumping ...
    (freebsd-arch)
  • Re: sensors fun..
    ... >> single-system sensors framework above. ... >> as I don't think userland data should be feed into the kernel. ... Instead, I think the "public" interface that systat, ...
    (freebsd-arch)
  • sensors fun..
    ... etc. sensors report status via an object like this ... - I'm not entirely opposed to having kernel drivers for various known sensor ... Forcing all sensors to be in the kernel. ... consequences in the kernel than in userland. ...
    (freebsd-arch)
  • Re: sensors framework continued (architecture)
    ... The official user interface to the sensors from userland ... interface in FreeBSD to export data from the kernel to the userland. ...
    (freebsd-arch)
  • Re: sensors fun..
    ... etc. sensors report status via an object like this instead of just getting some string out of a tool like 'mbmon'. ... - I'm not entirely opposed to having kernel drivers for various known sensor providers like lm, etc. OTOH, I could see a driver just providing ioctls to query the list of sensors and a sensor's value similar to using requests to the IPMI BMC to request SDR data via ioctls to /dev/ipmi0 as the kernel -> userland interface. ... A segfault has much more serious consequences in the kernel than in userland. ... That is, I think the kernel should provide a way to query a sensor (RAID drivers provide ioctls to communicate with the firmware, IPMI has ioctls to allow userland to communicate with the BMC, some drivers may provide ioctl/sysctl/whatever to read sensor values directly), but I don't think we should try to store history or extended state in the kernel. ...
    (freebsd-arch)