Starting the phosphor-hwmon service from udev rules

[Patrick Williams]

Matt,

We had a phone discussion last night with Joel, Andrew J, and Brad and I
was suppose to catch up with you today and never found time to.  (It was
half-impromptu and half-miscommunication on the desired topic.)

The net is that we came up with a third option for specifying these:

   1. Unique udev rules per device with corresponding environment file, and
      single systemd service, 
   2. Single udev rule per driver, unique systemd service file (with
      corresponding environment file?) per device.

   3. Single udev rule per driver, single template systemd service file per
      application (ex. phosphor-hwmon at .service), unique environment file
      per device.

On Tue, Nov 29, 2016 at 10:30:12AM -0600, Matt Spinler wrote:

> So now I think the rule would look something like:
> SUBSYSTEM=="hwmon", DEVPATH=="*i2c-3/3-0077/*", ACTION == "add", 
> TAG+="systemd", 
> ENV{SYSTEMD_WANTS}+="phosphor-hwmon-3-0077@/sys/class/hwmon/%k.service"

The 'SYSTEMD_WANTS' is useful if you want to trigger a specific
service.  If you leave that out, by default systemd triggers a @.device,
which other services can depend on.  sys-class-i2c-dev-i2c-3-0077.device
maybe in this case?

> and could use the Environment or EnvironmentFile directive in the 
> generated device specific unit file to pick up threshold vars.

In obmc-console at .service we have an example of using 'BindsTo'.  I think
we could write the phosphor-hwmon at .service to 'BindTo=sys-%i' and also
ConditionPathExists=/etc/conf.d/phosphor-hwmon-%i ,
EnvironmentFile=/etc/conf.d/phosphor-hwmon-%i ?

> Another issue I have is if the MRW should have the knowledge of if a 
> device has a hwmon driver or not?  While it would make things a lot more 
> simple if it did, I'm not sure if it's in its domain. If it doesn't, 
> then it would either still generate rules and unit files for every I2C 
> device and some just wouldn't get used, or we'd have to keep that 
> knowledge in our tree somewhere.
> Thoughts on that?

Doesn't it have to?  It isn't just that there is an lm77 sensor out on
an i2c bus and therefore we create the environment file.  The
environment file needs to have a decent amount of information, such as
what is the "NiceName" of the sensor ("FrontAmbient" maybe).  When you
talk about one of the MAX fan controller chips we potentially have
multiple fans on that chip so it more than one "sensor" worth of
configuration as well.  I can't imagine how the MRW data wouldn't
effectively encode that we expect the device to have an hwmon driver
(not directly, but indirectly by the presence of this 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/20161129/8fe76494/attachment.sig>