fmtopo -P flag does not appear to set properties
[root@00-25-90-95-89-50 ~]# /usr/lib/fm/fmd/fmtopo \\\\ -P facility.mode=uint32:0 \\\\ 'hc://:product-id=Joyent-Compute-Platform-1101:server-id=00-25-90-95-89-50:chassis-id=0123456789/chassis=0/bay=11?indicator=fail' TIME UUID Mar 16 06:32:33 be4cf245-1a74-c68c-fc1a-a1ca6a1eee48 hc://:product-id=Joyent-Compute-Platform-1101:server-id=00-25-90-95-89-50:chassis-id=0123456789/chassis=0/bay=11?indicator=fail group: facility version: 1 stability: Private/Private mode uint32 0x1 (ON)
I would expect this to set the value for mode to 0x0 (OFF). It does not, presently, seem to do that.
With some C code that uses topo_prop_set_uint32() directly, I am able to change the property (which has the side effect of toggling the LED state in the physical hardware).
To clarify, there are (perhaps at least) two kinds of properties: regular properties and dynamic properties.
Regular properties work as expected – we pass in an nvlist_t describing their name, type and value. This is hung off the topo_propval_t, replacing whatever was there to begin with.
The problem here is dynamic properties: essentially getters and setters, implemented in C. Though it is not clear to me where this is documented, or if it is merely lost to folklore and the sands of time, but it appears that all known dynamic property methods use a special set of "private" arguments to determine if they should operate in get mode or set mode. This private argument list is checked only for the value of the property, so we can just re-use the regular (non-private) argument list for this – as is done for the various topo_prop_set_* methods, via topo_prop_set.