Back from traveling, I just read the previous three messages to this thread.
On 08/17/2014 03:50 AM, Nicholas A. Bellinger wrote:
[...]
Jerome, any more thoughts..?
What I think is that there is no question that BCL _will_ eventually
cause problems because:
1) It is very difficult to enforce all tools (and possibly user scripts
using python/perl/whatever API bindings) to behave appropriately and
actually release the lock.
2) As Nic pointed out, we can't really assume that configfs IO is going
to return fast in all cases.
However, we need to balance that with our target use-case. Are we aiming
at providing a mere safeguard in situations were contention is low, as
Andy summarize before, or are we aiming at providing support for
concurrent configuration access ?
I think that both are good goals, and should be differentiated.
We could settle for BCL at the lowest level, aiming just at the
low-contention/for-safeguard-only lock case, and defer implementation of
a finer-grained mechanism at a higher level, maybe on top of the
configuration API.
The assumption here is that we expect two kind of tools and libraries:
1) Those providing or directly using configfs bindings (rtslib, perl
API) while following the locking convention.
2) Higher-level tools providing concurrent access to the configuration
and finer locking granularity, "config managers". Think automated cloud
storage provisioning.
The tradeoff we have to arbitrate if going with this is:
- Simple to implement and follow convention for writing new configfs
access layers means we immediately enable people to write kind 1 tools,
and be reasonably safe.
- A tool of kind 2 providing concurrent config management for remote
APIs would probably need close to exclusive access to configfs in order
to be robust, making it impossible to coexist with other kind 1 and kind
2 tools in any useful way.
If this is an acceptable tradeoff, then we know what to do, as BCL is
simpler to implement as a convention for low-level access.
If, however, there are use cases where we need two kind 2 high-level
"config managers" based on different configfs access layers to coexist,
then we should start thinking about a way to provide per-object locking
that can be reliably used by implementing a simple cross-language
convention.
What do you think?
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
