sensors framework continued (architecture)

[Nikolay Pavlov]

On Friday 09 November 2007 19:57:41 Alexander Leidinger wrote:
> This was addressed further down in the text (the part which you didn't
> quote here). The official user interface to the sensors from userland
> would be the userland library. As we are an open source OS, we can not
> hide something, we can only declare something as an official interface,
> or an internal interface. sysctl would allow to export the data in an
> hierarchical and unified way. sysctl is a well tested and working
> interface in FreeBSD to export data from the kernel to the userland.
>
> If or if not there are much changes and extensions in an incompatible
> way, can not be determined in such a high level architectural
> discussion. To be able to talk about this, we have to got more towards
> the implementation direction. But anyway, the userland access library
> we envision so far is supposed to handle this gracefully.
>
> The implicit question we answered here is, if we invent a new interface
> or augment an existing and well tested interface with some meta
> information in a subtree. So far it looks we want to use existing
> interfaces (a sysctl subtree for the data and devctl for notifications).
>
> What such an hierarchical and MIB like interface allows is, that you
> can get the notification "event sensor X switched to a critical value"
> and directly poll the value in an easy way. If, for example, you want
> to produce something similar via a pseudo-filesystem, you have to
> actually write a filesystem. This is a more complex task to get right
> than to use the functions in the kernel to handle sysctls. It also
> involves more processing in the kernel (mounting, VFS
> interaction, ...). With procfs we learned that a filesystem for
> something like this is hard to get right. After switching from procfs
> to sysctl's to gather data for top/ps/..., we noticed that it is more
> easy to get right via sysctl's, and that sysctl's are a good interface
> to export such data from the kernel.

Then it's ok for me :) 
But i think you should drop some unrealistic requirements:
Please do not define some event-latency thresholds here. So if it's to 
complicated to handle in kernel event triggers, just let the daemons do 
the job. FreeBSD is not RT OS in any way. 
An RFC already mentioned above show a good example of how the data could be 
exported to another world via SNMP (you can even generate traps via BSNMPD 
daemon), let's do not invent yet another "Group-level sensors framework". 
I am bit sceptic of it. So as an admin i would be happy with a daemon that 
could write some logs and trigger events, utility that could show current 
stats and SNMP MIB that could be listed via network. This just my 
requirements for sensors framework as a black box :) 
Thanks.

-- 
======================================================================  
- Best regards, Nikolay Pavlov. <<<-----------------------------------    
======================================================================  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20071109/f5cedfd7/attachment-0001.pgp