[OpenAFS] Red Hat Linux beta kernel implements AFS?

[Derek Atkins]

File a bug report with Red Hat! :)

-derek

Derrick J Brashear <shadow@dementia.org> writes:

> 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.
> 
> 
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available