phosphor-hwmon refactoring proposal

[Brad Bishop]

at 6:26 AM, Jeremy Kerr <jk at ozlabs.org> wrote:

> Hi Brad,
>
>> I have a quick phosphor-hwmon change proposal I’d like to get feedback
>> on.
>>
>> One issue with phosphor-hwmon that has been brought up a couple times
>> now  is that it gets its configuration settings from a file with a
>> path in the  filesystem that mirrors the path to the hwmon device in
>> the device tree.   This is problematic because the device tree path is
>> not required to be  stable, so whenever things move around there, the
>> config files all have to  be moved.
>
> Yep, sounds like we should find a better approach.
>
>> The proposal is simply to quit passing the configuration via the
>> environment and instead look for a config file, the location specified
>> via logic in the application, with a path like:
>>
>> /usr/share/phosphor-hwmon/i2c/2-004c.conf
>>
>> This is the path to the hwmon parent device relative to /sys/bus
>
> We want to ensure that any of those paths use persistent kernel
> naming/numbering though. In your example, we would need that i2c bus to
> be guaranteed to be probed as i2c bus id 2.
>
> There are facilities in place to ensure this happens, and as far as I
> know we are currently using those, but we will need to ensure that stays
> the case.

Can you elaborate a tiny bit on what the facilities are?  I just want to  
convince myself we are in fact using those.

> Would this be specific to each bus type? The example for i2c is good, as
> we do have a mechanism for persistent device paths under /sys/bus/i2c/,

We’ll need FSI+sbefifo too for the occ hwmon devices.  Are there facilities  
for stable bus id probing for FSI+sbefifo?

> but the same is not true for other bus types (eg, /sys/bus/platform). To
> handle that, we may want the paths to be of the form:
>
>  /usr/share/phosphor-hwmon/<bus>/<bus-specific-id>.conf

Slightly confused...I thought this is what I was trying to say :-)

The application would be passed the /sys/devices/… path on the command  
line, then find that device under /sys/bus/.  Once it has done that, it can  
extract <bus> and <bus-specific-id> from the discovered /sys/bus/… path.   
It then uses <bus> and <bus-specific-id> to construct the path to the  
config file, as you’ve spec’ed out.

> Where <bus> is from a predefined set of supported bus types, and

Why must they be pre-defined?  Is it because <bus-specific-id> may not be  
guaranteed to be stable for a given <bus> and we therefore need to ensure  
a-priori that they are stable before allowing users to use the program with  
hwmon devices on those bus types?

> <bus-specific-id> depends on that; it would typically be the name under
> /sys/bus/<bus>/devices, but we may want to introduce custom mappings
> perhaps?

I can’t think of any use case for custom mappings right now.  I did not  
think very hard about it though.

Are we desiging anything that would prevent us from adding the custom  
mappings later when we discover a need for them?

Thanks!

-brad