[OpenAFS] home on afs woes

Russ Allbery rra@stanford.edu
Wed, 11 Jan 2006 16:00:47 -0800


Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> Russ Allbery <rra@stanford.edu> wrote:

>> 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.

Ah, hm, I see what you're saying.  So basically, the API provided would be
only the k_* functions, namely:

    k_hasafs
    k_pioctl
    k_unlog
    k_setpag
    k_afs_cell_of_file

the two AFSCALL defines, the VIOC* defines, and struct ViceIoctl?

> 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.

I was trying for something minimally intrusive, which was ruling out
changing the name of the function (since otherwise I couldn't just reuse
the same code).  If we do something like the above, I wonder if it
wouldn't possibly be better to copy the required code into a new source
directory.  I'm not sure how best to do this cleanly.

> 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 Heimdal's.

Hm, that's a thought.  I'm not sure if that's a good idea either, but it
has some definite advantages.

On the other hand, it's rather a pain to deal with from a distribution
perspective, since you run into conflicts between the two libraries and
have to be careful about SONAMEs, library versioning, etc.  This can be
dealt with (both Heimdal and MIT provide a libkrb5, for instance), but
it's ugly.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>