[OpenAFS-devel] libkopenafs

[Russ Allbery]

Moving this to openafs-devel.  Decision needed for the 1.4.1 release
below.

Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> 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.

I took an extended look at how to implement this today.  My feeling is:
k_setpag and k_pioctl are fairly easy to deal with.  k_unlog is, I think,
ktc_ForgetAllTickets, but I don't entirely understand the implementation.
It does a lot of different things, probing kernel interfaces and trying a
couple of different APIs.  I think most of that code could be copied over,
though.  k_hasafs *might* be basically CHECK_KERNEL from auth/ktc.c, but I
don't know the code well enough.  I don't know how to do
k_afs_cell_of_file off-hand, but expect I could figure it out (from the fs
code, if nothing else).

> The AFSCALL defines are actually completely uninteresting to users of
> that API, since it doesn't provide any way to call arbitrary AFS
> syscalls.

Ah, yes, agreed.

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

We can build the list automatically at build time out of whatever header
file is currectly providing them.

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

Okay, now we need to figure out what we're going to do for 1.4.1, since
currently the libafssetpag code is on the release branch.  I was really
hoping to come back to this conversation before the last minute, but it's
been a really busy year so far.  :/

I don't want to provide a shared library that we later want to make go
away, or an API that we later want to get rid of.  I'd much rather use the
final names for what we really want to provide but only provide very
limited functionality and then grow it later.  I think providing something
like libkafs looks much more attractive than what I currently have done.
So I think we have three alternatives for the release branch:

 * Pull all the libafssetpag stuff off of the branch and plan on getting
   a libkopenafs into the next release.

 * A possibly less risky variation: leave the libafssetpag stuff as-is,
   but don't install it.  It can join all the other present but
   uninstalled stuff in OpenAFS until such time as we yank it and replace
   it with libkopenafs.

 * Change libafssetpag to libkopenafs (version .0.0) that provides only
   a k_setpag and that as a wrapper around lsetpag.  We can then work on
   preventing conflicts with libsys, adding the other functions, and
   cleaning up where and how it builds later on.  (And providing a header
   file.)

What do people think?  I can implement any of these options this weekend.

> Well, we more or less need a separate directory for each library we
> build; that's just how the build system is.

Yeah, but it's a stupid part of the build system that really wouldn't be
horribly difficult to fix, as near as I can tell.  This is caused mostly
by the way that certain file names are hard-coded into the build rules for
building shared libraries.

What we do need, right now at least, is a separate directory for building
the shared library if we're also building a static library.  Either that,
or one has to create a subdirectory and hack around in Makefile to build
the PIC objects in a subdirectory.  This is the sort of thing that libtool
fixes; it's a little annoying to deal with otherwise, but not horrible.

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