dbus-sensors:hwmontemp: additional attribute proposal

[James Feist]

On 8/7/2020 10:17 AM, Jason Ling wrote:
>       feel like this approach already isn't optimal as in reality most
>     systems aren't going to have half of those sensors, and you're then
>     creating useless matches for things that don't matter to your platform.
> 
> I'm assuming that you're referring to the general approach of PSUSensors 
> and not referring to extending the list using a config file?
> If so then I agree.
> I'm also a bit confused about scanning every hwmon attribute on the 
> system and seeing if has a name that is in the permit list..then seeing 
> if it has an appropriate configuration. Why not just grab the 
> configuration and using that information navigate to the appropriate 
> hwmon path and take what is there? (Why even bother with validating the 
> driver name?) . Any context would be helpful; I'm trying to grok the design.
> 
>     Maybe something like allowing a device to be exported with a different
>     keyword other then 'type' in Entity Manager would allow us to just use
>     one PSUSensor config type, then your export could be hidden in your EM
>     config?
> 
> Sure, or maybe a catchall type for something PSUSensor can consume (and 
> bypass the name check?)

Yeah that's what I meant, a generic PSUSensor Type with a field called 
'Export' or something that EM can use to get the Export type.

> 
> On Fri, Aug 7, 2020 at 10:06 AM James Feist <james.feist at linux.intel.com 
> <mailto:james.feist at linux.intel.com>> wrote:
> 
>     On 8/7/2020 9:54 AM, Jason Ling wrote:
>      >> What about making the device/type lists in PSUSensors extendable
>     using JSON?
>      >
>      >     Say more about what you're wanting to do here.....
>      >
>      >   Take
>      >
>     https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L43 and
> 
>      >
>     https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L59 and
> 
>      > make it so those can be extended using (for example) without an
>     upstream
>      > code change. I picked JSON as the easiest example.
>      > IIRC PSUSensors does validity checks to make sure that the device
>     emits
>      > a name in its 'permit list' (hwmontempsensor is less picky) so
>     tricking
>      > PSUSensors into gathering telemetry for a non-public device is
>     tricky.
> 
>     I feel like this approach already isn't optimal as in reality most
>     systems aren't going to have half of those sensors, and you're then
>     creating useless matches for things that don't matter to your platform.
>     Maybe something like allowing a device to be exported with a different
>     keyword other then 'type' in Entity Manager would allow us to just use
>     one PSUSensor config type, then your export could be hidden in your EM
>     config?
> 
> 
>      >
>      >     Can you give an
>      >     example of what you would use it for?
>      >
>      > Sure, the primary use case would be
>      > It's a non public device. Would rather not broadcast information
>     about
>      > it or have to obfuscate the device name. Really would rather not
>      > maintain patches until the device is made public.
>      >
>      >
>      >
>      > On Fri, Aug 7, 2020 at 9:39 AM Ed Tanous <ed at tanous.net
>     <mailto:ed at tanous.net>
>      > <mailto:ed at tanous.net <mailto:ed at tanous.net>>> wrote:
>      >
>      >     On Fri, Aug 7, 2020 at 9:36 AM Jason Ling
>     <jasonling at google.com <mailto:jasonling at google.com>
>      >     <mailto:jasonling at google.com <mailto:jasonling at google.com>>>
>     wrote:
>      >      >
>      >      > Slightly different topic:
>      >      > What about making the device/type lists in PSUSensors
>     extendable
>      >     using JSON?
>      >      >
>      >
>      >     Say more about what you're wanting to do here.....  Can you
>     give an
>      >     example of what you would use it for?
>      >
>