Date: Fri, 5 Oct 2012 18:24:37 +0200 From: Lars Engels <lars.engels@0x20.net> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: drivers for desktop hardware monitoring chips Message-ID: <20121005162437.GF7416@e-new.0x20.net> In-Reply-To: <506F06FA.4050804@FreeBSD.org> References: <506F06FA.4050804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--kb0TSCuX821Ar6UT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 05, 2012 at 07:12:42PM +0300, Andriy Gapon wrote: >=20 > Currently FreeBSD is severely lacking in support for basic hardware monit= oring on > desktop-class systems. Such systems typically do not have IPMI or other = similar > types of agents. Instead they usually have a hardware monitoring functio= n in a > Super I/O chip or less frequently in a dedicated chip. > Popular manufacturers of such chips are Nuvoton (formerly Winbond) and IT= E. >=20 > FreeBSD doesn't provide any support for this hardware neither in kernel n= or in > base system userland tools. There are a number of tools in ports (e.g. m= bmon), > but they are of varying quality and most of them are very out-of-date. S= o they do > not properly support recent (and no so recent) hardware. >=20 > The userland tools are dying out mostly because most of other popular ope= rating > systems have built-in support for such hardware and thus there is no ince= ntive to > support any cross-platform userland utilities. Which is not trivial too,= because > of different policies and interfaces to access system/hardware resources. >=20 > So I think that it is time that we also provide some support for this kin= d of > hardware and for users who have it. > Fortunately, our "otherBSD" friends have drivers that support the most po= pular of > desktop hardware monitoring chips. It seems that the drivers in OpenBSD,= NetBSD > and DragonflyBSD (unsurprisingly) share most of the code and are collecti= vely > maintained. > lm(4) driver supports Winbond/Nuvoton lineage, while it(4) supports ITE c= hips. > For me personally these two drivers cover hardware monitoring in 100% of = machines > I regularly use (Gigabyte and Asus desktops). >=20 > So I would like to import these drivers into FreeBSD with as minimal code= changes > as possible. That should make future imports and multi-way code sharing = much easier. >=20 > The problem is these drivers make use of some common infrastructure known= as > "Sensors Framework". This "Sensors Framework" (along with the drivers) w= as once > ported to FreeBSD during a GSoC project by Constantine A. Murenin. It ev= en was > committed to the tree, but then reverted. That happened because the arch= itecture > and design of the "Sensors Framework" framework didn't match a concept of= a > Sensors Framework that FreeBSD developers had in mind, nor their expectat= ions > about such a framework. >=20 > I have been maintaining the code in my own git repository and regularly r= ebased it > on top of recent head. Now I want to re-use the work of others and to > re-introduce the code into the tree. > But I do _not_ want to call it a "Sensors Framework". Especially I do no= t want to > call it _the_ "Sensors Framework". > I do not want to say that the code implements some vision. > I do not plan to convert any other drivers to make use of the code. > I do not propose any policy that the future drivers should be based on th= e code. > At this moment I do not plan to commit any other drivers besides lm(4) an= d it(4), > but I won't object if someone else does it either. > I do not plan to work on any "smart" sensor stuff or on controlling hardw= are via > sensors code (setting thresholds, fan speeds, getting interrupts, etc). > I will never object to development of a proper SF. I will try to convert= the > current code to the proper SF when it happens. >=20 > For me it is just an easy way to get it(4) and lm(4) in the base and to s= upport > them with minimal effort. So I would like to call this code "it(4) and l= m(4) > drivers plus some shared utility code for kernel drivers for a small numb= er of > simple sensors". > I would like to emphasize "kernel drivers", "small number" and "simple se= nsors". >=20 > I like that the code uses sysctl as an interface to access sensors. sysc= tl is > quite convenient to use in kernel. It is very convenient in userland (fo= r command > line and programmatic access). It is totally adequate to query a few ver= y simple > values. Besides, this is what is already used all over the place albeit = in a > non-systematic fashion: coretemp(4), amdtemp(4), acpi_thermal(4), etc. > So this is the aspect of the code that I would like to keep. >=20 > Obviously, I would also like to keep the kernel side interfaces for ease = of > porting of the individual drivers. >=20 > If any other aspect of the code is too intrusive, abusive or inefficient = to be > committed in the current form, I am prepared to re-work or remove it (wit= hin the > above constraints). >=20 > I do not plan to start committing anything just yet, so this is an advanc= e notice > about my intentions. I'll be here to discuss technical and other sides o= f these > plans. >=20 > Please let me know what you think. > Any suggestions, objections, comments, help, etc are very welcome. > Thank you in advance. >=20 > P.S. Please please let's not discuss what happened back then. Please. > P.P.S. Of course I will notify cnst, netchild, syrinx and others about th= e plans. > All the attributions will definitely be made/kept. Can you give us a link to the code in question? --kb0TSCuX821Ar6UT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBvCcUACgkQKc512sD3afiRjwCfWAUuARBkr58u9cp2sbm24jaF Yy8An3ru9rCNIBfR0to3kwbJzZ/IPr4O =FCzV -----END PGP SIGNATURE----- --kb0TSCuX821Ar6UT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121005162437.GF7416>