From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 19:03:56 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 20E8D16A421 for ; Fri, 9 Nov 2007 19:03:56 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 4984913C4B7 for ; Fri, 9 Nov 2007 19:03:52 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so500333nfb for ; Fri, 09 Nov 2007 11:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=fznop7CxdB5OJ6Sk33YYYVC2rUMZsWNsGYV49Q0nNwE=; b=Lx2QUotYjnYd9ESxLooLMzf8kVkPEZT4YYjJnJPs17nR/tPdNKCeH6WSGihRafvtlxi4DS5MF5NJp/ZaokRgKjiej+ItvDYI9U52kr2eqtH1Q7bAmiNLfXFq+ys8WHMQU8VbCA5r4QYJaOkeVngfVqSD7OHTCA5+6c5hejSNQBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=HrxEEkdsEez2DNghF5ngWJLs1QcJZX2Na8wtkq+1AsUrmtaOOYWr0nRp2hxzmfrglEs+3LCi/FfBqFMCuF1XXw6jVjqNOAT3TO6b7xpvWLPKdEExE88ZR+WtdTY3eYUdMskoGbk1RPjCx9Q7cglf1wPvCOFM8/DgTXutYcMF2PM= Received: by 10.78.151.3 with SMTP id y3mr2829822hud.1194635023335; Fri, 09 Nov 2007 11:03:43 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id b36sm3141520ika.2007.11.09.11.03.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2007 11:03:42 -0800 (PST) From: Nikolay Pavlov To: Alexander Leidinger Date: Fri, 9 Nov 2007 21:03:43 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> <20071109185741.13930f0b@deskjail> In-Reply-To: <20071109185741.13930f0b@deskjail> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1672619.TaOcxpx39Z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200711092103.48652.qpadla@gmail.com> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 19:03:56 -0000 --nextPart1672619.TaOcxpx39Z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 09 November 2007 19:57:41 Alexander Leidinger wrote: > This was addressed further down in the text (the part which you didn't > quote here). The official user interface to the sensors from userland > would be the userland library. As we are an open source OS, we can not > hide something, we can only declare something as an official interface, > or an internal interface. sysctl would allow to export the data in an > hierarchical and unified way. sysctl is a well tested and working > interface in FreeBSD to export data from the kernel to the userland. > > If or if not there are much changes and extensions in an incompatible > way, can not be determined in such a high level architectural > discussion. To be able to talk about this, we have to got more towards > the implementation direction. But anyway, the userland access library > we envision so far is supposed to handle this gracefully. > > The implicit question we answered here is, if we invent a new interface > or augment an existing and well tested interface with some meta > information in a subtree. So far it looks we want to use existing > interfaces (a sysctl subtree for the data and devctl for notifications). > > What such an hierarchical and MIB like interface allows is, that you > can get the notification "event sensor X switched to a critical value" > and directly poll the value in an easy way. If, for example, you want > to produce something similar via a pseudo-filesystem, you have to > actually write a filesystem. This is a more complex task to get right > than to use the functions in the kernel to handle sysctls. It also > involves more processing in the kernel (mounting, VFS > interaction, ...). With procfs we learned that a filesystem for > something like this is hard to get right. After switching from procfs > to sysctl's to gather data for top/ps/..., we noticed that it is more > easy to get right via sysctl's, and that sysctl's are a good interface > to export such data from the kernel. Then it's ok for me :)=20 But i think you should drop some unrealistic requirements: Please do not define some event-latency thresholds here. So if it's to=20 complicated to handle in kernel event triggers, just let the daemons do=20 the job. FreeBSD is not RT OS in any way.=20 An RFC already mentioned above show a good example of how the data could be= =20 exported to another world via SNMP (you can even generate traps via BSNMPD= =20 daemon), let's do not invent yet another "Group-level sensors framework".=20 I am bit sceptic of it. So as an admin i would be happy with a daemon that= =20 could write some logs and trigger events, utility that could show current=20 stats and SNMP MIB that could be listed via network. This just my=20 requirements for sensors framework as a black box :)=20 Thanks. =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1672619.TaOcxpx39Z Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHNK8U/2R6KvEYGaIRAlLkAJ4+Cd+bKsSqAVsKpACJHJKXct6PYACfYWTW mp3PfXt6vMlkkymOjVVTobY= =Cq/Z -----END PGP SIGNATURE----- --nextPart1672619.TaOcxpx39Z--