Date: Fri, 9 Nov 2007 21:03:43 +0200 From: Nikolay Pavlov <qpadla@gmail.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: cnst@freebsd.org, arch@freebsd.org, rwatson@freebsd.org, freebsd-arch@freebsd.org, imp@freebsd.org Subject: Re: sensors framework continued (architecture) Message-ID: <200711092103.48652.qpadla@gmail.com> In-Reply-To: <20071109185741.13930f0b@deskjail> References: <20071109124421.3c1901b1@deskjail> <200711091851.19445.qpadla@gmail.com> <20071109185741.13930f0b@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711092103.48652.qpadla>