2013-09-01 14:57 keltezéssel, Gémes Géza írta:
Hi,
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?
Cheers
Geza Gemes
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
Sorry if I wasn't clear with my intentions. I plan to have a python
interface, where all the parts (volumes, pts entries, cache, etc) would
be represented as objects. So basically I plan to have a few classes
like volume, pts, cache, bos, with properties reflecting their state and
methods for manipulating them.
Cheers
Geza Gemes
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
