dbus-sensors:hwmontemp: additional attribute proposal

[Jason Ling]

> 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.
>
Sure, I think that handles the EM side of things.

I'm conflicted on that.  Part of the reason that list is there, and
> not in the config files directly, is to convey that those are the
> types that have been tested to work correctly, and the types that the
> config files "promise" to work sanely.  The other thing is, if you've
> done the testing, adding to that list is (should be) relatively
> trivial and straightforward.  Opening up that list to runtime parsing
> opens a lot of security questions I'm not prepared to answer.

Sure, let's scrap runtime parsing and go for something far simpler.
(1) have a base type, devices list that represents the approved device list.
(2) have an empty extended type, device list that represents user specified
extensions.
(3) factor these out into separate files and provide a method that returns
the union of the base and extended types/devices.

now we have a base type/device list that contains supported guaranteed
devices and another extended type/device list that is easier to maintain
patches for.
I think that's a rather small change and accomplishes what I'd like while
preserving the intent of keeping a list of supported types/devices.
What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200807/6f8332da/attachment-0001.htm>