From owner-freebsd-arch@FreeBSD.ORG Fri Oct 19 14:24:31 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 142F316A417; Fri, 19 Oct 2007 14:24:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id A863913C48A; Fri, 19 Oct 2007 14:24:30 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A564CA.dip.t-dialin.net [84.165.100.202]) by redbull.bpaserver.net (Postfix) with ESMTP id EA4CD2E325; Fri, 19 Oct 2007 16:24:05 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 025A45B480D; Fri, 19 Oct 2007 16:22:59 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9JEMxWK086710; Fri, 19 Oct 2007 16:22:59 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 19 Oct 2007 16:22:59 +0200 Message-ID: <20071019162259.7qjnk9dlyccw4oww@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 19 Oct 2007 16:22:59 +0200 From: Alexander Leidinger To: John Baldwin References: <200710171245.36949.jhb@freebsd.org> <200710181450.38224.jhb@freebsd.org> <20071019113444.xinyc37x9cg0ckk0@webmail.leidinger.net> <200710190841.48129.jhb@freebsd.org> In-Reply-To: <200710190841.48129.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.427, required 8, BAYES_00 -15.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, TW_BK 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org, "Constantine A. Murenin" Subject: Re: sensors fun.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 14:24:31 -0000 Quoting John Baldwin (from Fri, 19 Oct 2007 08:41:47 -0400= ): > On Friday 19 October 2007 05:34:44 am Alexander Leidinger wrote: >> Quoting John Baldwin (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