Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Nov 2007 18:51:10 +0200
From:      Nikolay Pavlov <qpadla@gmail.com>
To:        freebsd-arch@freebsd.org
Cc:        cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, Alexander Leidinger <Alexander@leidinger.net>, imp@freebsd.org
Subject:   Re: sensors framework continued (architecture)
Message-ID:  <200711091851.19445.qpadla@gmail.com>
In-Reply-To: <20071109124421.3c1901b1@deskjail>
References:  <20071109124421.3c1901b1@deskjail>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart3093353.TiXXcl7AEI
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 09 November 2007 13:44:21 Alexander Leidinger wrote:
> Robert thinks that sysctl MIBs offer "a more semantically rich and, to
> be honest, better defined way of interacting with live subsystems than
> device files do in a generic sense". Nobody objected to this opinion or
> provided reasons why a fd based approach is better than a sysctl MIB
> based approach. Ricardo Nabinger Sanchez points out
> http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs).

I think a MIB approach is much more usefull between "Single-system sensors=
=20
framework" and "Group-level sensors framework" and a good example here is=20
a SNMP(the general usage example of the MIB defined in rfc3433). I am not=20
a kernel developer and don't know whether it's a good for pass the data or=
=20
not, but as experienced administrator should mansion that sysctl mib's is=20
expected (IMHO) to be used as a configuration interface to define a kernel=
=20
and system behavior. It's much more easy to use userland utilities such as=
=20
vmstat, systat, netstat, sockstat than listing some stats and data via=20
sysctl. Also i suspect that such complex and rich thing as sensors=20
framework often would be a subject to various changes and extensions, so i=
=20
vote to hide kernel part as much as possible.=20

=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


--nextPart3093353.TiXXcl7AEI
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)

iD8DBQBHNJAH/2R6KvEYGaIRAgkhAJ44iVEo9wz2IpZiZ3wlacG/iqifBwCfaEkn
/6NDikrU+K+mbEd7WeAwVX8=
=vPmq
-----END PGP SIGNATURE-----

--nextPart3093353.TiXXcl7AEI--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711091851.19445.qpadla>