[OpenAFS] home on afs woes
Wed, 11 Jan 2006 18:42:41 -0500
On Wednesday, January 11, 2006 03:15:56 PM -0800 Russ Allbery
> Jeffrey Hutzelman <firstname.lastname@example.org> writes:
>> No it doesn't. All it needs is a relatively simple library which
>> provides a way to check for the presence of AFS and to make AFS system
>> calls, particularly setpag and pioctl.
>> Conveniently, heimdal comes with such a library; it's called libkafs and
>> includes functions like k_hasafs(), k_pioctl(), k_unlog(), and
>> k_setpag(). IIRC, Derrick used to distribute a standalone version of
>> this library for people not using Heimdal, but it's probably pretty
>> stale by now.
> Certainly such a library would be useful. If someone wants to implement
> it without all of the dependencies that Heimdal libkafs has, I'd be all in
> favor of it. Heimdal's libkafs has significant dependencies and isn't
> really suitable for use outside of a system built with Heimdal in general.
That's true for the full libkafs, but not for the functions I mentioned.
>> Ugh. lsetpag() is not really intended to be a public interface. The
>> public interface provided by AFS is called setpag().
> Providing setpag in a shared library that's actually maintainable is,
> right now, unfeasible in OpenAFS without a great deal of work. If you
> don't agree, please do say so, but I looked at it somewhat seriously and
> it was way more work that I thought was likely to happen. It requires,
> for instance, pulling in all of Rx.
I was talking about interfaces, not implementations. I don't have any
problem with a library which implements the setpag() API without rmtsys
support. But a library which exports only lsetpag() is not all the useful.
>> Also, I'd suggest that instead of a shared library containing only
>> lsetpag, it might be better to provide a library containing the
>> functions I named above, with the same API that the KTH folks have been
>> distributing for years.
> I think it would be better, yes, but it's a lot more work if you want to
> really match APIs, since that requires providing krb_afslog and
The functions I named don't require providing krb_afslog or krb5_afslog.
They are just an API for making AFS syscalls.
I'm not sure if this is the right approach, but we could even provide a
library named libkafs.so, containing only the k_* functions I mentioned,
with the idea being that we'd eventually provide the rest (hopefully
eliminating the need for Kerberos implementations to do so), and in the
meantime, people who want the full interface can replace our library with