Project

General

Profile

Bug #4017

fmtopo -P flag does not appear to set properties

Added by Robert Mustacchi over 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Category:
lib - userland libraries
Start date:
2013-08-08
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

For example:

[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.

History

#1

Updated by Robert Mustacchi about 6 years ago

  • Status changed from New to Resolved

Resolved in 1410cb930a3e26032c59c6835837a28c47366b3c.

Also available in: Atom PDF