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>