[OpenAFS-devel] Progress on Linux in-kernel RxRPC library

Derrick J Brashear shadow@dementia.org
Sun, 20 Mar 2005 22:19:30 -0500 (EST)


On Sun, 20 Mar 2005, Kyle Moffett wrote:

>>> what format the Kerberos stuff is in, you only care that _something_
>>> understands it enough to give you an OpenAFS token when you want one.
>> 
>> Well, that's not entirely true. The RPC layer needs to be able to choose a
>> single credential out of the cache it has.
>
> Fine, so tell call_usermode_helper to set the KEY_ID environment variable
> before calling the program.

I think we're talking at cross purposes here. What would that accomplish?
What I'm getting at is I assume (something) writes the kerberos credential 
cache into a key.

Actually I guess you're assuming it writes each credential into a key (so 
krbtgt/LOCAL.REALM in one, afs/cell.name in another, host/my.machine in 
another)?

>>> They wouldn't.  The RxRPC library would notice that you used the same
>>> credentials for both calls and automatically use the same connection.
>>> If it wants to do more simultaneous RxRPC calls than the protocol
>>> allows, it would create the extra connections for you when you need
>>> them, and close them when you're done.
>> 
>> Ok. Well, we have that now.
>
> Yes, but this was just the continuation of the "get rid of PAGs on Linux"
> part of the discussion.

If they were tied to a session instead of a PAG they'd still work the same 
way. In fact, you can ignore the specific "encoded as groups" implementation
(which is not the essense of a PAG, it's just one way of doing it) you 
can just s/PAG/session/g if it helps.

>> It's always inode/filesystem stuff which screws us, and that won't help
>> at all. I'd estimate 70% of the pain is there, and much of it could go
>> away if we used system inodes. If we could have something for free, that
>> would be my first wish.
>
> Does OpenAFS use the cachefs in 2.6, or is cachefs still too immature and
> missing too many features to be useful?

It doesn't. I haven't looked recently to see what features it has. It may 
be useful. If it's missing anything I'd guess without looking it's 
something related to security, but that's wildly stabbing in the dark.

>  Also, what does OpenAFS require
> for its inodes that Linux doesn't currently provide?

Actually, that I can tell, it requires nothing there hasn't been since 
2.2 except for someone's time to implement use of them.