drivers for desktop hardware monitoring chips

[Lars Engels]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20121005/ea6aa93c/attachment.pgp