Hi AndersBj,

Reviewed the patch.
Ack.

/Neel.


On Friday 24 April 2015 06:13 PM, Anders Bjornerstedt wrote:
>   osaf/services/saf/immsv/README               |   6 +++---
>   osaf/services/saf/immsv/README.SASTRINGT_API |  15 ++++++++-------
>   2 files changed, 11 insertions(+), 10 deletions(-)
>
>
> diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README
> --- a/osaf/services/saf/immsv/README
> +++ b/osaf/services/saf/immsv/README
> @@ -406,10 +406,10 @@ on-going directed at some object that th
>   But The AdminOwner mechanism is an access-control mechanism, not a 
> concurrency
>   control mechanism. After access has been granted, in this case for an
>   admin-operation, there is no real point in insisting that the 
> admin-ownership
> -must be valid until the admin-op completes. An AdminOwnerReelease/Clear will
> +must be valid until the admin-op completes. An AdminOwnerRelease/Clear will
>   return ERR_BUSY if there is an ongoing CCB, since it is unknown if 
> additional
> -operations are to be addeded. Opeartions may be added to the CCB by the OI
> -itself using the AuggmentedCcb interface. With respect to interferference
> +operations are to be added. Opeartions may be added to the CCB by the OI
> +itself using the AugmentedCcb interface. With respect to interference
>   from other overlapping admin-operation requests or other ccb-requests, the
>   OpenSAF IMM leaves it open to the OI implementation to handle or reject.
>   The OI dispatch is always via one single thread, but the OI may internally 
> be
> diff --git a/osaf/services/saf/immsv/README.SASTRINGT_API 
> b/osaf/services/saf/immsv/README.SASTRINGT_API
> --- a/osaf/services/saf/immsv/README.SASTRINGT_API
> +++ b/osaf/services/saf/immsv/README.SASTRINGT_API
> @@ -12,8 +12,8 @@ Defining an attribute in an IMM class de
>   also setting the flag SA_IMM_ATTR_DN, will mean that the attribute is 
> intended
>   to hold a value that should be a DN.
>   
> -Other flags that make sense to also set on in combination with SA_IMM_ATTR_DN
> -when applicable are:
> +Other SaImmAttrFlagsT values that also make sense to set in combination with
> +SA_IMM_ATTR_DN when applicable are:
>   
>   SA_IMM_ATTR_RDN if this is the RDN attribute. Just as having SaNameT the
>   type of an RDN attribute indicates that the class is an association class,
> @@ -26,12 +26,13 @@ attributes of type SaStringT if the SA_I
>   The exception is the RDN attribute which still can not have the
>   SA_IMM_ATTR_NO_DANGLING set.
>   
> -All the other flags may also be used in combination with SA_IMM_ATTR_DN, with
> -the normal meaning. But the only attribute *type* that can be combined with
> -SA_IMM_ATTR_DN flag is the type SA_IMM_ATTR_SASTRINGT.
> +All the other SaImmAttrFlagsT values may also be used in combination with
> +SA_IMM_ATTR_DN, with the normal meaning. But the only attribute *type* that
> +can be combined with SA_IMM_ATTR_DN flag is the type SA_IMM_ATTR_SASTRINGT.
>   
> -The SaStringT API provides the same functions as the SaNameT based API with 
> almost the
> -same semantics as the A.2.X spec. Where there is a difference this is 
> commented below.
> +The SaStringT API provides the same functions as the SaNameT based API with
> +almost the same semantics as the A.2.X spec. Where there is a difference this
> +is commented below.
>   --------
>   
>       /* 4.5.1 saImmOmSearchInitialize() */


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to