[OpenAFS] jafs et al
Tue, 13 Mar 2007 01:04:56 -0500
> From: Peter Somogyi <email@example.com>
> Reply-To: firstname.lastname@example.org
> Organization: Gamax Kft
> To: email@example.com
> Subject: Re: [OpenAFS] jafs et al
> Date: Mon, 12 Mar 2007 14:43:06 +0100
> User-Agent: KMail/1.9.1
> Cc: Marcus Watts <firstname.lastname@example.org>
> References: <200703120646.BAA17428@quince.ifs.umich.edu>
> In-Reply-To: <200703120646.BAA17428@quince.ifs.umich.edu>
> MIME-Version: 1.0
> Content-Type: text/plain;
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> Message-Id: <email@example.com>
> > how many people use jafs, jafsadm?
> > (=lib/libjafsadm.so, jafs.jar, org.openafs.*, etc.)
> > what do you use it for?
> > what version of java do you use?
> > what version of openafs?
> > which hardware architecture(s)?
> > do you use kaserver, kerberos 5, ?
> > if you use kerberos 5 with java elsewhere,
> > which java k5 library?
> > do you have any sample code or applications
> > that use this in interesting ways?
> See also http://rt.central.org/rt/Ticket/Display.html?id=21930
> + search for jafs by content with query builder in rt to see its history
> + google on this list
Yes. What I started with is the java support in 1.5.15, which
already includes all 3 of your patches.
It is good to know the history of this -- the file src/libuafs/README
that appears to go with this is only willing to talk about
openafs 1.2. and redhat linux 7.3, far older than your work.
I have already found older google messages - they were helpful in
terms of understanding my more stupid mistakes, like
-DSystem.loadLibrary=. I haven't seen anything that suggests
anybody is actually using jafs for anything real.
Following is the patch I worked up to build on amd64_linux
+ sun jdk 1.5:
the start explains what changed. This is probably almost clean
enough to submit as a patch to RT -- except I'm not convinced it
actually works or would be of use. Note this doesn't address kaserver
vs. k5 at all. It does further address 64-bit problems, and also
one linking/threading issue.
Your patch turned on pic code for (nearly) all of openafs. This isn't
necessarily ideal, nor is it (mostly) necessary. There's a performance
loss in statically linked binaries that might bother people running
servers built that way. The patch I have above turns pic code for
libuafs & libadmin, and builds pic static libraries for libafsrpc &
libafsauthent. This is probably not ideal either, but at least