From owner-cvs-all@FreeBSD.ORG Thu Oct 18 06:44:34 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4544B16A417; Thu, 18 Oct 2007 06:44:34 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 92BE213C469; Thu, 18 Oct 2007 06:44:33 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from outgoing.leidinger.net (p54A548C8.dip.t-dialin.net [84.165.72.200]) by redbull.bpaserver.net (Postfix) with ESMTP id 8DE8E2E0BD; Thu, 18 Oct 2007 08:44:26 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 638A45B480D; Thu, 18 Oct 2007 08:43:20 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9I6hJKi067730; Thu, 18 Oct 2007 08:43:19 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 18 Oct 2007 08:43:19 +0200 Message-ID: <20071018084319.7whfk1pixt8o080w@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 18 Oct 2007 08:43:19 +0200 From: Alexander Leidinger To: Julian Elischer References: <70e8236f0710150343k590f5be8r8cdf3fd60df4abd2@mail.gmail.com> <4713700D.8040202@samsco.org> <20071015193658.138fc9a5@deskjail> <4713A871.1080608@errno.com> <47165D09.7040909@elischer.org> In-Reply-To: <47165D09.7040909@elischer.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.404, required 8, BAYES_00 -15.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, SARE_FROM_SPAM_WORD3 0.10) X-BPAnet-MailScanner-From: netchild@freebsd.org X-Spam-Status: No Cc: Scott Long , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, Barros , cvs-all@FreeBSD.org, Wilko Bulte , Sam Leffler , Joao Subject: Re: cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf f X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 06:44:34 -0000 Quoting Julian Elischer (from Wed, 17 Oct 2007 =20 12:05:45 -0700): > Sam Leffler wrote: >> Alexander Leidinger wrote: >>> Quoting Scott Long (Mon, 15 Oct 2007 07:50:05 -0600)= : > > keep in mind htere are a lot of people out here that have no opinion > as we haven't looked at it in detail, who may like the idea of a sensor > framework but don't know enough about this implementation to chime in. I keep this in mind. What I complain about is, that Poul hasn't looked =20 into the implementation. He said he doesn't like the _idea_ of a =20 sensors framework. He wasn't even complaining about the architecture, =20 he was saying the idea is crap without technical backing. I asked him =20 several times to bring specific technical points on the table, either =20 an explanation what is bad about the architecture or something the =20 implementation itself, but he didn't. He just repeated that the idea =20 itself is crap. If he would come up with understandable technical =20 arguments why something is not good, I wouldn't complain, but he =20 doesn't. He's major complaint is, that he doesn't like the idea itself. > Having spent some time in past lives supporting various sensors, > I know that there is a crying need for some sort of framework Maybe you should explain this to Poul, it seems I failed to explain =20 him why we would benefit from such kind of a framework. > but that doesn't mean that it needs to be this one, or even in the kernel. I see several levels of stuff which can be named "sensors framework" here. One level is in the kernel. It's just an export interface to transfer =20 status data from the kernel to userland. The goal of this framework is =20 IMO to "collect" all this data in the kernel and provide a single =20 point of contact for the userland to query this in-kernel data. That's =20 what the soc project was about. Let's call this kernel sensors =20 framework here. Then there's something in the userland, what can also be named =20 "sensors framework". This part would be responsible to be a single =20 point of contact for to query the status data of the entire system. =20 This userland part would be responsible to collect data which is =20 exported from the kernel, and to collect data from userland stuff. It =20 would provide an interface to be able to query the in-machine data =20 (some people may say SNMP can be used for this). Let's call this =20 single-system sensors framework here. And then there's something in the network what can be named "sensors =20 framework". This part would be responsible to collect sensor data in =20 the entire (sub-)network and provide an interface to query the data =20 from the entire (sub-)network (an example can be nagios or some =20 commercial offering). Let's call this group-level sensors framework =20 for now. The term "sensor data" may by ambiguous too. When I talk about sensor =20 data, this can be some data from a device, like =20 temperature/voltage/humidity/tv channel/ rotation speed/pressure =20 level/fill level/coordinates/whatever (what we want to include of this =20 stuff or not I don't talk about, e.g., ATM I don't see a need to =20 provide the TV channel via the sensors framework). Sensor data can =20 also be the status of a subsystem in the kernel, some database related =20 things in userland, the hitrate per second of a webserver, or =20 whatever. All (more or less) of those things may in the end need to =20 arrive in the group-level sensors framework. Before they arrive there, =20 they ideally arrive in the single-system sensors framework (reduces =20 probing complexity and the amount of work of the person who has to =20 configure the group-level sensors framework). And parts of this stuff =20 was in the kernel sensors framework before. The group-level sensors framework doesn't belong into FreeBSD IMO. For =20 the single-system sensors framework I have no strong opinion (and with =20 bsnmp we may have some sort of this already which just needs to be a =20 little bit extend (MIBs), but this depends upon your needs and =20 expectations). For a kernel sensors framework it is clear, that this =20 can not live it ports. To me the benefits of such a framework is =20 obvious. For several other people @FreeBSD.org I have the impression, =20 that it is also obvious. I don't object if someone brings up valid technical arguments why the =20 sensors framework this thread is all about is not suitable for =20 FreeBSD. Look into my mails, you see I specially ask for technical =20 arguments against it. But I object if someone just says it is crap =20 without providing technical backing. I didn't write the code, it's not =20 my baby, and if someone finds major flaws in it which can not be =20 corrected, shoot it. No objections from my side. But saying that the =20 idea is crap which makes it even not worth looking into this sensors =20 framework, while several people think we need something like this, is =20 far from being polite. And that's the reason why I object. I don't say it's the best architecture ever. But I say it serves a lot =20 of needs, is an improvement of the current situation, and is not done =20 in a very very bad way. Whoever comes up with an better way of doing =20 it is welcome by me, but he should take into account that this =20 specific sensors framework is shared with more than one other BSD and =20 allows code sharing (I'm not talking about implementation details, I'm =20 talking about the syntax/semantic). If suggested improvements =20 outweight the benefits from sharing the code, great, it's welcome by =20 me (and maybe the other BSDs are interested in those improvements too, =20 if they are not in a way which prevents the adoption those =20 improvements). > Maybe we can find someone to arbitrate. We used to have an architecture > board for this purpose but we got rid of it. I think the outcome at that time was to ask core@, and they may decide =20 to ask the people which formed the architecture review board before =20 (or people which have a lot of knowledge in the specific area). Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 The Martian Canals were clearly the Martian's last ditch effort!