I agree that if the cryptographic verification took longer than the N
namespace traversals and permission checking that would occur in the
other case, that this would be a silly proposal. honestly that didn't
occur to me as even remotely possible, especially given that in most
cases the server will be verifying the exact same handle lots of times,
rather than needing to verify a large number of different handles
simultaneously (in which case there's no point in using openg()/openfh()).
I agree that not being able to clearly define the lifetime of the handle
is suboptimal.
If the handle is a capability, then its lifetime would be bounded only
by potential revocations of the capability, the same way an open FD
might then suddenly cease to be valid. On the other hand, in Andreas'
"open file handle" implementation the handle might have a shorter lifetime.
We're attempting to allow for the underlying FS to implement this in the
most natural way for that file system. Those mechanisms lead to
different lifetimes.
This would bother me quite a bit *if* it complicated the use model, but
it really doesn't, particularly because less savvy users are likely to
just continue to use open() anyway.
I agree; the real problem is that POSIX .1 is being used to specify
semantics over multiple systems in a cluster. But we're stuck with that.
Thanks,
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html