<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What would happen if something wasn't in the approved devices list?<br>Print a warning? Assert? I don't have any problems with this approach.<br></blockquote><div>I think currently in PSUSensors if the name of the device isn't in <a href="https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L59">pmBusNames</a>  then PSUSensors refuses to monitor that particular device (<a href="https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L269">https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L269</a>). </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It would be nice if this list could be (in the future) extended to all<br>sensor types.</blockquote><div>Sure, I'll start with PSUSensors first.</div><div> </div><div></div><div><br></div><div>A quick word about the original topic of this thread; we picked hwmontemp sensors where possible because we've seen performance issues for PSUSensors (could be N seconds before Sensor.Value gets updated to dbus). This has undesirable implications for PID loops..<br></div><div>thought was that spreading temp sensors over into hwmontemp sensor where possible would help mitigate the performance issue until we can figure out a better long term solution.</div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 7, 2020 at 11:17 AM James Feist <<a href="mailto:james.feist@linux.intel.com">james.feist@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/7/2020 11:04 AM, Jason Ling wrote:<br>
> <br>
>     Yeah that's what I meant, a generic PSUSensor Type with a field called<br>
>     'Export' or something that EM can use to get the Export type.<br>
> <br>
> Sure, I think that handles the EM side of things.<br>
> <br>
>     I'm conflicted on that.  Part of the reason that list is there, and<br>
>     not in the config files directly, is to convey that those are the<br>
>     types that have been tested to work correctly, and the types that the<br>
>     config files "promise" to work sanely.  The other thing is, if you've<br>
>     done the testing, adding to that list is (should be) relatively<br>
>     trivial and straightforward.  Opening up that list to runtime parsing<br>
>     opens a lot of security questions I'm not prepared to answer.<br>
> <br>
> Sure, let's scrap runtime parsing and go for something far simpler.<br>
> (1) have a base type, devices list that represents the approved device list.<br>
> (2) have an empty extended type, device list that represents user <br>
> specified extensions.<br>
> (3) factor these out into separate files and provide a method that <br>
> returns the union of the base and extended types/devices.<br>
> <br>
> now we have a base type/device list that contains supported guaranteed <br>
> devices and another extended type/device list that is easier to maintain <br>
> patches for.<br>
> I think that's a rather small change and accomplishes what I'd like <br>
> while preserving the intent of keeping a list of supported types/devices.<br>
> What do you think?<br>
<br>
What would happen if something wasn't in the approved devices list? <br>
Print a warning? Assert? I don't have any problems with this approach. <br>
It would be nice if this list could be (in the future) extended to all <br>
sensor types.<br>
</blockquote></div>