[OpenAFS] home on afs woes

[Jeffrey Hutzelman]

On Wednesday, January 11, 2006 04:00:47 PM -0800 Russ Allbery 
<rra@stanford.edu> wrote:

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

Actually, I'm not sure why k_afs_cell_of_file is interesting; I thought 
that was just a pioctl.  But it could be thrown in for good measure.

The AFSCALL defines are actually completely uninteresting to users of that 
API, since it doesn't provide any way to call arbitrary AFS syscalls.  As 
for the VIOC defines, we should do something, but I'm not too thrilled with 
the idea of OpenAFS containing two independently-maintained lists of those.

I suppose I don't get to complain about that until I start distributing an 
authoritative header to go with the tables at grand.central.org/numbers.


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

echo 'int setpag(void) { return lsetpag(); }' | gcc -x c -c - -o setpag.o

:-)

(what's sad is that on my amd64_linux26 machine, that produces a 1344-byte 
file, of which 16 bytes are actually code.  Talk about bloat!


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

Well, we more or less need a separate directory for each library we build; 
that's just how the build system is.  So essentially what you need is to 
build src/sys/afssyscalls.c in more than one place.  That's not too hard; 
we do it in several places already.  It would presumably need some bashing 
to be able to provide both sets of interfaces.  I'm wary of implementing 
lpioctl in terms of k_pioctl or vice versa, because that sounds like it's 
asking for symbol conflicts if someone uses libsys and libkafs (ours or the 
real one) in the same binary.


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

True.  Like I said, I'm not sure it's the right approach, but it might be. 
Some distribution pain might be worth people being able to build AFS-aware 
apps that can be built against either heimdal or openafs without requiring 
the other to be present...

-- Jeff