Starting the phosphor-hwmon service from udev rules

[Matt Spinler]

On 11/28/2016 8:42 PM, Patrick Williams wrote:
> On Mon, Nov 28, 2016 at 10:31:20AM -0600, Matt Spinler wrote:
>> 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.
> This was a detail I missed before.  systemd service files natively have
> the variable 'ENVFILE'.  If they don't automatically take the ENVFILE
> from the environment (via udev invocation) then I would rather we use
> unique systemd service files instead of unique udev rules.  Having the
> systemd service file launch some kind of piped shell processing is
> problematic and certainly not preferred.
>

OK. The only way for the udev rule to send something directly into the 
service file is with the template parameter, and that needs to take the 
device path, since that isn't known ahead of time.  (Unless the service 
wants to parse its %i into multiple values?)

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"

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

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161129/a89b8779/attachment.html>