Starting the phosphor-hwmon service from udev rules

[Joel Stanley]

On Tue, Nov 29, 2016 at 3:01 AM, Matt Spinler
<mspinler at linux.vnet.ibm.com> wrote:
> I am working on a story this sprint to start the phosphor-hwmon service from
> udev rules.  In addition to just starting the service based on a device
> path, I need to be able to communicate to it some threshold values, like
> critical high temps for example.

What are the functions of the 'phosphor-hwmon' service?

I would consider naming it phosphor-hardware-monitor or similar, in
case you decide it should monitor things other than Linux 'hwmon'
devices.

>
> I have a proposal for the rules at
> https://gerrit.openbmc-project.xyz/#/c/1243/.
>
> It has lines like:
>
> SUBSYSTEM=="hwmon", DEVPATH=="*i2c-3/3-0077/*", ACTION == "add",
> TAG+="systemd",
> ENV{SYSTEMD_WANTS}+="phosphor-hwmon@/sys/class/hwmon/%k.service",
> ENV{ENVFILE}+="/etc/hwmon.d/hwmon-bmp280-3-77.conf"

Do we need to match only on the path? Can it match on the device driver instead?

>
> where the .conf file will contain any threshold values, maybe like CRIT=50.
> The command line in the unit file would then somehow make a udevadm call to
> pull out the ENVFILE so it can get passed into the executable along with the
> device path.
>
> Is this the recommended way to go about doing this?  Or instead of having a
> separate udev rule for each device, but 1 service file, is it better to have
> 1 udev rule but separate service files?

It appears you plan on re-implementing the functionality of the
lm-sensors package. While the upstream project has dissappeared from
the net, the source code and documentation is still available. I would
consider firstly trying to re-use existing daemons and configuration
that we already have access to. If that does not work, then reading
and re-using the source code to adopt the same design would save you
time and effort.

https://web.archive.org/web/20150905145034/http://www.lm-sensors.org/

Cheers,

Joel