From: Patrick Williams <patrick@stwcx.xyz>
To: Matthew Barth <msbarth@linux.ibm.com>
Cc: OpenBMC List <openbmc@lists.ozlabs.org>
Subject: Re: sdbusplus - const/readonly flags
Date: Tue, 25 Aug 2020 13:08:51 -0500 [thread overview]
Message-ID: <20200825180851.GL3532@heinlein> (raw)
In-Reply-To: <fb22f956-19df-b44f-5ae9-113f6443c2e9@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-25 18:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-25 15:00 sdbusplus - const/readonly flags Patrick Williams
2020-08-25 17:50 ` Matthew Barth
2020-08-25 18:08 ` Patrick Williams [this message]
2020-08-25 20:52 ` Adriana Kobylak
2020-08-26 15:10 ` Patrick Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200825180851.GL3532@heinlein \
--to=patrick@stwcx.xyz \
--cc=msbarth@linux.ibm.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.