dbus-sensors:hwmontemp: additional attribute proposal

[Jason Ling]

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


On Fri, Aug 7, 2020 at 10:06 AM James Feist <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>> wrote:
> >
> >     On Fri, Aug 7, 2020 at 9:36 AM Jason Ling <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?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200807/1c986fe9/attachment-0001.htm>