[OpenAFS-devel] libkopenafs

[Jeffrey Hutzelman]

On Friday, March 17, 2006 04:08:08 PM -0800 Russ Allbery <rra@stanford.edu> 
wrote:

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

k_unlog is VIOCUNLOG.


> k_hasafs *might* be basically CHECK_KERNEL from auth/ktc.c, but I
> don't know the code well enough.

k_hasafs is both a test and an initialization routine.  Users of the 
library are expected to call this before anything else, and not to use any 
of the other interfaces if it returns false.  It needs to actually return 
accurate results, though, so a VIOCNOP or the like seems appropriate.


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

k_afs_cell_of_file is VIOC_FILE_CELL_NAME


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

At this point, we should not be making any changes to 1.4.1 that are not 
critical bug fixes.


-- Jeff