[OpenAFS] Red Hat Linux beta kernel implements AFS?

[Derrick J Brashear]

On Mon, 19 Aug 2002, Rudolph T Maceyko wrote:

> While looking over the latest beta of Red Hat Linux, I found this 
> interesting item:
> 
> > Kernel Notes
>   .
>   .
>   .
> >    The kernel in this beta contains a preliminary code drop of a new
> > implementation of the AFS network file system. Please note that this
> > implementation is not complete and this feature may be removed in the
> > final release.
> 
> I'm just looking at it now, but I don't see any other documentation 
> about it yet.  Perhaps if I install their kernel-source RPM I'll see 
> more information about this.  I was able to find some references to 
> xfs/Arla in the kernel-docs RPM, so maybe that's all this comment is 
> really about.

Presumably "no caching". This is sort of one of those things I have mixed
feelings about. On one hand, it takes away from the client we have, which
is portable, so now new features need to be ported to another code base,
and developer resources, already scarce, are split further. On the other,
having an independant implementor would help keep people honest, but I
don't think this brings more to the table in that regard than Arla. 

Presumably it is intended to end up Linuxly-correct and not "works like
other AFS clients", which would be unfortunate in environments where more
than one platform is supported. 

You can say the existing Linux client is a headache, and it is. It could
probably be sorted out if the dentry caching in Linux were fully
documented (all the functions filesystems might use, not just the 5 or
whatever they think you might care about), for instance. Other things that
would be useful would be
-a real way to add or modify syscalls, given the sys_call_table method is
being broken. Not just give us the ability to add one syscall, give us the
ability to do what we need (see below)
-until sufficient developer time is found to split inodes and vcaches, a
way to call the kernel inode initializer on inodes the kernel didn't
create

With just these things I think we could have a very stable client. I'm sad
to see the effort going into providing yet another AFS instead of
addressing these issues, much of which I could address with a small set of
patches in a matter of hours which then would never be adopted for
mainline kernels.

> The note piqued my curiosity even more once I found that stock 
> openafs-1.2.6 won't run:
> 
> [root@osgood i386]# insmod /usr/vice/etc/modload/libafs-2.4.18-11-i686.o
> /usr/vice/etc/modload/libafs-2.4.18-11-i686.o: unresolved symbol 
> sys_call_table
> /usr/vice/etc/modload/libafs-2.4.18-11-i686.o:
> Hint: You are trying to load a module without a GPL compatible license
>       and it has unresolved symbols.  Contact the module supplier for
>       assistance, only they can help you.

Yeah, they broke it for everything, the sys_call_table isn't exported
anymore. Even if we get a way to add an afs_syscall, how we're supposed to
do PAGs is beyond me. You can unbreak it by compiling the kernel with the
sys_call_table exported again.