On 08/19/2014 01:46 PM, Jerome Martin wrote:
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?
So you're saying we have a simple BCL but we let an entity grab and hold it continuously, so all future accesses need to go through the entity?
-- Andy -- 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
