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

[Kyle Moffett]

On Mar 22, 2005, at 00:28, Chaskiel M Grundman wrote:
> Each cached vnode has a pointer to a linked list of struct axscache
> entries. Each entry maps a pag/user id to it's effective access
> rights.

Ok, this seems reasonably simple.  On Linux under the new scheme the
struct axscache would, instead of mapping pag/uid to effective rights,
map an afstoken key id to effective rights.  You would need to utilize
the destruction of an afstoken key to iterate through a linked-list of
all axscache objects and invalidate them so that a future key with the
same id would not be assumed to have any remaining cached access, but
that doesn't seem overly complicated.

>> I'm just trying to understand what part of the existing Linux
>> filesystem cache is insufficient for OpenAFS to utilize without
>> resorting to patched-in external caches.
> Are you talking about the current pagecache, or the as yet
> non-mainline cachefs?

Either one.  I'm interested in your comments/thoughts on both.

> If the latter, then it probably is or could be made sufficient. The
> following things would be needed.

This is good to know.  I'm not working on cachefs, but the archived
copy of this message will be a useful reference for the cachefs devs.

> It comes back to that portability issue though. Having a 'better'
> interface to use on linux does not help us on the other platforms,
> and actually increases complexity by requiring some sort of
> abstraction layer that can be used to provide uniform access to the
> two cache implementations.

I understand and agree with you.  On the other hand, it can be argued
that creating such an abstraction layer would help clean up the code
and modularize it to a certain extent, as well as allow it to utilize
similar features of other OSes as they are developed.

> Also, at what point do we cross the line alluded to in
> <http://www.linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html>,
> and become code "written for linux" instead of "(a filesystem) ported
> from other operating systems"?

I don't think you're anywhere near this line at this point.  If you
abstracted the cache management into a separate interface and use
different code on Linux and elsewhere, I think it's easily arguable
that in porting to Linux you could just "throw away" certain extra
parts of the cache code for the Linux version and use the caching
API provided by the OS instead of duplicating it in the module.  In
that case, you _clearly_ are not a derivative.


Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------