Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Oct 2007 16:22:59 +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:  <20071019162259.7qjnk9dlyccw4oww@webmail.leidinger.net>
In-Reply-To: <200710190841.48129.jhb@freebsd.org>
References:  <200710171245.36949.jhb@freebsd.org> <200710181450.38224.jhb@freebsd.org> <20071019113444.xinyc37x9cg0ckk0@webmail.leidinger.net> <200710190841.48129.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting John Baldwin <jhb@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@freebsd.org> (from Thu, 18 Oct 2007  =20
>> 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  =20
>> so it can be
>> > reexported to userland.  Instead, I think the "public" interface  =20
>> that systat,
>> > monitoring daemons, SNMP, etc. should be a userland interface  =20
>> that can have
>> > multiple backends.  It can pull data from a sensor implemented in =20
>>  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-back=
ed
> sensors should be a "public" interface, but a private backend that only th=
e
> sensors framework uses.  The "public" interface that tools and users, etc.
> should be using is the library.  Basically, in your three levels of sensor=
s

Like libkvm does for the abstraction of the underlying implementation =20
(ok, libkvm does not only abstract the interface to the kernel, but I =20
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 wo=
uld
> be the userland interface.

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

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

Bye,
Alexander.

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

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?20071019162259.7qjnk9dlyccw4oww>