sensors fun..

Alexander Leidinger Alexander at Leidinger.net
Fri Oct 19 07:24:31 PDT 2007


Quoting John Baldwin <jhb at freebsd.org> (from Fri, 19 Oct 2007 08:41:47 -0400):

> On Friday 19 October 2007 05:34:44 am Alexander Leidinger wrote:
>> Quoting John Baldwin <jhb at freebsd.org> (from Thu, 18 Oct 2007   
>> 14:50:37 -0400):
>>
>> > On Thursday 18 October 2007 07:39:49 am Alexander Leidinger wrote:
>> >> 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?
>> >
>> > Nowhere do I suggest to feed userland data into the kernel just   
>> so it can be
>> > reexported to userland.  Instead, I think the "public" interface   
>> that systat,
>> > monitoring daemons, SNMP, etc. should be a userland interface   
>> that can have
>> > multiple backends.  It can pull data from a sensor implemented in  
>>  userland or
>> > a sensor implemented in the kernel.
>>
>> I was thinking you talk about the interface between the kernel and the
>> userland. Now I think that you talk more or less about something which
>> could be implemented e.g., as an userland library which not only polls
>> the kernel sensors framework, but provides the single-system sensor
>> data (and could be a base of a singe-system sensor daemon which feeds
>> its data to a group-level sensors framework). Does this sound like
>> what you have in mind?
>
> Yes.  And I don't think that the kernel-userland interface for kernel-backed
> sensors should be a "public" interface, but a private backend that only the
> sensors framework uses.  The "public" interface that tools and users, etc.
> should be using is the library.  Basically, in your three levels of sensors

Like libkvm does for the abstraction of the underlying implementation  
(ok, libkvm does not only abstract the interface to the kernel, but I  
don't think this detail is important ATM)? Good idea IMO.

> I think the first level should be an implementation detail that is free to
> change if needed as it won't be a "public" API.  The stable, public API would
> be the userland interface.

Would you mind using "official"/"internal" instead of  
"public"/"private"? I think this is a better description, as in an  
open source project a lot is public, even if it is an internal  
interface. This would make the discussion more unambiguous IMO.

Regarding making the kernel sensors framework an implementation detail  
that is free to change, I agree with you too, this makes it more  
future proof and allows to survive evolutionary improvements (if they  
are needed) without the headache of the need to keep the  
kernel-userland interface compatible.

Bye,
Alexander.

-- 
The following statement is not true.
The previous statement is true.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137


More information about the freebsd-arch mailing list