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
smime.p7s
Description: S/MIME Cryptographic Signature
