[OpenAFS] building swig based interfaces

Gémes Géza geza@kzsdabas.hu
Sun, 01 Sep 2013 14:57:52 +0200

> On 9/1/2013 6:27 AM, Gémes Géza wrote:
>> Hi,
>> I've decided to start a project for building a swig based python
>> interface for afs commands/functions. The advantage is that a swig
>> interface can be further used for creating interfaces for other
>> languages. Currently I know about only one limited python-afs interface
>> which calls the afs binary commands instead of implementing an interface
>> to the C code (https://github.com/openafs-contrib/afspy). On the other
>> hand the (to my knowledge) only interface: AFSPerl
>> (http://cpansearch.perl.org/src/NOG/AFS-2.6.3/) uses suboptimal
>> interfaces making it incompatible with 1.6.x and 64 bit
>> (https://lists.openafs.org/pipermail/openafs-info/2012-September/038684.html).
>> So if you can give me some pointers about where should I look in the
>> openafs source for the declaration of different functions? My first
>> guess would be the files in libadmin, but I'm probably wrong :-(
>> Thank you in advance!
>> Cheers
>> Geza Gemes
> In theory you would be correct that libadmin would be the proper place
> to look.  libadmin provides a library interface to a subset of the
> various command sets and was used by IBM to build both the Java
> interface and the AFS Server Manager and User Manager applications on
> Windows.  Unfortunately, neither the Java classes nor the Manager tools
> have been well maintained during the OpenAFS era.  As libadmin had no
> consumers it too did not receive much attention and all of the bug fixes
> and functionality improvements which were added to the command line
> interfaces were not applied to libadmin.
> The PIC vs non-PIC library issues described in the 2012 mail thread
> apply to libadmin as well as the rest of the code base.   It is an
> architectural issue.  The perl-AFS for 1.4 as implemented simply could
> not work without PIC versions of all dependencies.  These are available
> in current 1.6 releases but not 1.4 releases.
> A broader set of long term problems for perl-AFS and any SWIG interface
> is the code called by the command line tools is not guaranteed to be
> thread safe nor are there any interfaces that are guaranteed to be
> stable across OpenAFS releases.  An additional problem is that if the
> language supports loading and unloading of modules, the OpenAFS RX
> library is not safe to unload as it cannot properly shutdown its worker
> threads and cleanup its global state information.
> The goal of a stable, thread safe set of bindings for Python, Perl,
> Java, and perhaps Ruby and Powershell is admirable one.  There are a
> couple of approaches that can be taken:
> 1. Start by defining the SWIG interface in terms of the functionality
>     that will be exposed to callers but implement it in terms of the
>     command line interfaces.   This will permit the language binding
>     to be reviewed and obtain real work use.
> 2. After the SWIG interface is considered stable begin to work on the
>     OpenAFS command line tools to refactor their sources into a thread
>     safe library that isolates the user interface (input, output,
>     error handling, logging) from the operational functions.
> 3. As each library is ready for use substitute the command line calls
>     with the C library functions while maintaining the stability of
>     the language specific binding.
> Another approach would be to back port all of the changes to the command
> line tools to libadmin but I do not believe that project would be
> worthwhile.  In order for the libraries to be maintained moving forward
> they have to be used within the OpenAFS source tree and that effectively
> means they must be used by the command line tools.
> I hope this is helpful.
> Jeffrey Altman
Sorry if it sounds nitpickering, but I want to be sure, I didn't 
misunderstood your idea.
In a nutshell your proposal for me is to design a swig interface around 
exec calls for the existing binaries (like bos, vos, fs, etc.)? And 
after having a stable interface try to modify the backend part of the 
interface, to call into the underlying code?


Geza Gemes