Starting the phosphor-hwmon service from udev rules

[Matt Spinler]

On 11/29/2016 8:19 PM, Patrick Williams wrote:
> 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 ?
The issue with this is the %i is the device path of the hwmon driver, 
which looks like
/devices/platform/ahb/ahb:apb/1e78a000.i2c/i2c-0/i2c-0/0-0068/hwmon/hwmon0,
and the hwmon<num> can't be known ahead of time by the MRW so it can't make
conf files named that way.

This means the the environment file has to be explicitly set in the 
service file,  so I'd
need to generate unique service files.  (Or phosphor-hwmon just
builds its own env file names based on segments from its device path.)


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