Lines Matching refs:MUST

86 PF instances **MUST NOT** mutate each others.
115 A PF **MUST** be able to handle parameters.
120 A parameter **MUST** have a value.
124 A PF **MUST** support mutable parameters.
128 This value **MUST** be settable for a mutable parameter.
169 If a type is chosen to be supported, it **MUST** respect all MUST clause,
187 PF **MUST** support integer with invariant size.
191 The API to access it **MUST** respect C integer ABI.
384 A syncer **MUST** be mapped to one or more parameters.
388 One parameter **MUST NOT** be mapped to two or more syncer.
389 Ie: a parameter MUST be mapped to zero or one syncer.
394 A syncer **MUST** support retrieving the mapped parameters value from the mapped
399 A syncer **MUST** support setting the mapped parameters value to the mapped
424 The PF **MUST** be able to create syncers.
446 A syncer builder **MUST** have a unique identifier in its containing syncer
452 A syncer library **MUST** have a unique identifier in the host system.
518 When a syncer reports an out-of-sync condition, the PF **MUST** try to resync
548 Set of values for different parameters. A configuration **MUST NOT** contain 2
568 A PF **MUST** offer configurations as described in the Definition chapter.
574 Each configuration **MUST** be associated with a predicate that condition its
593 A selection criterion **MUST** have one, and only one, state at a given time.
596 A selection criterion **MUST** have a always known immutable domain of definition.
597 Ie All the possible state that a selection criterion can take **MUST** be known
606 The selection criterion possible states **MUST** be specifiable by directly a
635 Function (in the mathematical sense) that **MUST** given selection criteria
649 The API to change criterion values **MUST** allow atomicity regarding
650 configuration application. I.e. it **MUST** be possible to change multiple
670 It **MUST** always be able to express a selection criterion rule from a given
672 I.e.: a criteria **MUST** always have a state that can be matched by a rule.
719 There **MUST** be a mechanism to avoid ambiguity on multiple configuration eligibility
727 <ko>It is not a MUST because this goal could also be achieve with (for
732 If multiple configuration are eligible, the first one **MUST** be applied.
738 If no configuration is eligible, no configuration **MUST** be applied.
745 Parameter set and get order MUST not change the final state.
753 This is contradictory with the fact that parameters MUST be accessed independently.</why>
778 The PF data **MUST** be deserializable.
853 Every parameter **MUST** have an identifier that uniquely identifies it.
861 Two PF instances with the same parameters **MUST** have the same identifier for
1097 This value **MUST** be gettable for an immutable parameter.