<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div>Sure, I think that handles the EM side of things. </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">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.</blockquote><div>Sure, let's scrap runtime parsing and go for something far simpler. </div><div>(1) have a base type, devices list that represents the approved device list.</div><div>(2) have an empty extended type, device list that represents user specified extensions.</div><div>(3) factor these out into separate files and provide a method that returns the union of the base and extended types/devices.</div><div><br></div><div>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.</div><div>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.</div><div>What do you think? </div></div></div>