sdbusplus - const/readonly flags
Patrick Williams
patrick at stwcx.xyz
Wed Aug 26 04:08:51 AEST 2020
On Tue, Aug 25, 2020 at 12:50:06PM -0500, Matthew Barth wrote:
> On 8/25/20 10:00 AM, Patrick Williams wrote:
> >
> > ALSO: I could really use the help of the domain experts for the
> > phosphor-dbus-interfaces listed in the gist[4] to review and determine
> > if 'const' or 'readonly' is more appropriate.
>
> From the info you provided, sounds like the ThermalMode interface's
> Supported property needs to be updated to "readonly" as there may be a
> reason where the supported thermal modes are changed by the server of
> the interface due to machine configuration differences.
>
Yes. In that case 'readonly' + 'emits_change' is probably most
appropriate, since you want a signal sent out if that property does ever
change value. ('emits_change' is the default for most properties if you
have NO flags, but once you start adding other flags it no longer
becomes defaulted).
> > What does this mean for us? A few thoughts.
>
> Are there any code update implications after these interfaces are
> changed from const to readonly that would require code changes by the
> server code implementing them?
I don't think changing from const to readonly has any implications to
the implementations (assuming they are using the sdbus++ generated
server classes). The existing code already prevented clients from
writing to 'const' properties and 'readonly' will do the same. The only
difference should be relative to the ability to emit signals, if
desired, and the implication that a client should never need to re-fetch
a const property.
--
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200825/5baaa742/attachment.sig>
More information about the openbmc
mailing list