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
[-- Attachment #1 --] On Fri, Oct 05, 2012 at 07:12:42PM +0300, Andriy Gapon wrote: > > Currently FreeBSD is severely lacking in support for basic hardware monitoring on > desktop-class systems. Such systems typically do not have IPMI or other similar > types of agents. Instead they usually have a hardware monitoring function in a > Super I/O chip or less frequently in a dedicated chip. > Popular manufacturers of such chips are Nuvoton (formerly Winbond) and ITE. > > FreeBSD doesn't provide any support for this hardware neither in kernel nor in > base system userland tools. There are a number of tools in ports (e.g. mbmon), > but they are of varying quality and most of them are very out-of-date. So they do > not properly support recent (and no so recent) hardware. > > The userland tools are dying out mostly because most of other popular operating > systems have built-in support for such hardware and thus there is no incentive to > support any cross-platform userland utilities. Which is not trivial too, because > of different policies and interfaces to access system/hardware resources. > > So I think that it is time that we also provide some support for this kind of > hardware and for users who have it. > Fortunately, our "otherBSD" friends have drivers that support the most popular of > desktop hardware monitoring chips. It seems that the drivers in OpenBSD, NetBSD > and DragonflyBSD (unsurprisingly) share most of the code and are collectively > maintained. > lm(4) driver supports Winbond/Nuvoton lineage, while it(4) supports ITE chips. > For me personally these two drivers cover hardware monitoring in 100% of machines > I regularly use (Gigabyte and Asus desktops). > > 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. > > The problem is these drivers make use of some common infrastructure known as > "Sensors Framework". This "Sensors Framework" (along with the drivers) was once > ported to FreeBSD during a GSoC project by Constantine A. Murenin. It even was > committed to the tree, but then reverted. That happened because the architecture > and design of the "Sensors Framework" framework didn't match a concept of a > Sensors Framework that FreeBSD developers had in mind, nor their expectations > about such a framework. > > I have been maintaining the code in my own git repository and regularly rebased 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 not 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 the code. > At this moment I do not plan to commit any other drivers besides lm(4) and 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 hardware 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. > > For me it is just an easy way to get it(4) and lm(4) in the base and to support > them with minimal effort. So I would like to call this code "it(4) and lm(4) > drivers plus some shared utility code for kernel drivers for a small number of > simple sensors". > I would like to emphasize "kernel drivers", "small number" and "simple sensors". > > I like that the code uses sysctl as an interface to access sensors. sysctl is > quite convenient to use in kernel. It is very convenient in userland (for command > line and programmatic access). It is totally adequate to query a few very 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. > > Obviously, I would also like to keep the kernel side interfaces for ease of > porting of the individual drivers. > > 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 (within the > above constraints). > > I do not plan to start committing anything just yet, so this is an advance notice > about my intentions. I'll be here to discuss technical and other sides of these > plans. > > Please let me know what you think. > Any suggestions, objections, comments, help, etc are very welcome. > Thank you in advance. > > 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 the plans. > All the attributions will definitely be made/kept. Can you give us a link to the code in question? [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBvCcUACgkQKc512sD3afiRjwCfWAUuARBkr58u9cp2sbm24jaF Yy8An3ru9rCNIBfR0to3kwbJzZ/IPr4O =FCzV -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121005162437.GF7416>