Starting the phosphor-hwmon service from udev rules

Patrick Williams patrick at stwcx.xyz
Tue Nov 29 13:39:34 AEDT 2016


On Tue, Nov 29, 2016 at 11:58:32AM +1030, Joel Stanley wrote:

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

phosphor-hwmon is an implementation of these dbus interfaces, which
sources its information from the Linux hwmon interfaces:

https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/Sensor

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

An alternative source of data should be in a separate application /
repository.  The non-hwmon-specific should be mostly contained in the
generated dbus bindings, so there is no or very little overlap between
different implementations.

> > 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?

The driver name is insufficient to differentiate between two different
sensors of the same device type.  For instance, the front and rear
ambient may both be LMxx-class devices, but have different dbus paths
and potentially different thresholds.

> > 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.

Can you give more details on which aspects you feel there is overlap?

In any case, your questions and critiques should all be directed at Brad
who is implementing phosphor-hwmon and not Matt who asked specifically
about how to launch the application from MRW-based information?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161128/82c9fd30/attachment.sig>


More information about the openbmc mailing list