On 08/05/2014 03:27 PM, Jerome Martin wrote:
I disagree a little. The kernel's configfs API is the cornerstone. So
for locking, we need a standard that is at that level, as well as an
implementation in rtslib. There are already alternative LIO APIs in Perl
and shell for example, and there are bound to be more.
If locking gets implemented on the kernel side, them of course it should
be supported at the rtslib level, so that several rtslib instances along
with whatever runs alongside in perl or bash can use the configfs if
needed. Even if it does not (I have no clue if this is a good idea or
not, you guys doing the kernel bits know better), we could implement a
convention at that level for userspace. No problem with that.
My original comment was made with something different in mind though. I
was anticipating concurrent usage of a single instance of rtslib - with
a remote API on top for instance - or concurrent targetcli/lio shell
usage on one system. In both cases, the new config API - part of rtslib
- could provide partial locking per target, of even per target
subsystem. This is different from the low-level locking that Andy
mentions, and has more to do with semantics for concurrent access to the
"system configuration" abstraction provided by the new config API.
I don't believe any kernel code needs to be changed, it's just a matter
of developing and announcing a convention that other accessors would be
expected to follow. One that I prototyped a while back was lockf() on
/var/run/target.lock for everything, but we could define finer
granularity locking too. A given library used by multiple clients could
have each client try to acquire the global lock, or acquire it once and
then handle concurrency its own way.
Regards -- Andy
p.s. I'm cribbing this technique from git://linux-nfs.org/nfs-utils
utils/exportfs/exportfs.c, seems like the same issue as what they're
solving in a similar manner.
--
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
