Date: Fri, 05 Oct 2012 19:12:42 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-arch@FreeBSD.org Subject: drivers for desktop hardware monitoring chips Message-ID: <506F06FA.4050804@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?506F06FA.4050804>