Yes, but the patch did not allow for
- partial sharing (keys are bound to _one_ PAG, and one PAG only)
This makes "revoke" pretty much useless, since you have a damn hard
time finding all the keys, since you have to copy them around instead
of sharing one instance.
It also makes grouping very hard.
- the name space is so limited that you _have_ to consider the PAG ID's
temporary, which means that you have to add a whole new layer of
maintenance in user space.
Neither of these are apparently problems in the AFS world, because there
is only one entity that gives out keys, so that one entity can keep track
of every key ever allocated.
But look at the big picture. What happens when you have multiple sources
of keys that have nothing to do with each other. How do you maintain
sanity in that kind of world, when the numbers don't have any meaning, and
one of the key maintainers doing a "join" operation will throw away
all the work that the other key maintainers did.
> Linus seems to be arguing for multiple PAGs, like multiple
> GIDs. But I think that functionality is really there, inside the PAG.
No it isn't. You can't do independent joins, since as it is, the code has
an "all or nothing" approach.
Again, this works in a single-use environment, where there is central
control. It _sucks_ if you want to have a generic "bunch of keys" model.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/