On 2006-01-28, Simon Barner <barner@...> wrote:
> I'd also be happy with a document describing the various FUSE APIs. I brows=
> your website, and did some research, but I could not find anything that wou=
> have been verbose enough for me...
My intention was to create one. I didn't really get there, but I
collected some real-life patches (just for the purpose of easing porting
to FreeBSD, but in fact, it's platform dependent, any API upgrader can
make use of them):
If you are porting Python bindings, you might be particularly interested in my
preliminary Perl binding API upgrade:
Not just because it's another scripting language, but also because these
seem to use the same API version (21).
I'd be happy to get feedback on the usability of these sample ABI
upgrade patches (my secret hope is hearing "they are damn very well
useable", because in that case I could forget about my planned "API
Changelog" without feeling guilty :)).
> +#define FUSE_USE_VERSION 25
> +#include <sys/types.h>
> +#include <sys/param.h>
> +#include <sys/mount.h>
> #include <Python.h>
This seems to be OK.
> #include "fuse.h"
> #include <time.h>
> @@ -140,7 +144,8 @@
> goto out_decref;
> - ret =3D df(dh, PyString_AsString(o0), PyInt_AsLong(o1));=09
> + /* XXX */
> + ret =3D df(dh, PyString_AsString(o0), PyInt_AsLong(o1), 0);=09
> @@ -345,7 +350,7 @@
> fst->f_bavail =3D retvalues;
> fst->f_files =3D retvalues;
> fst->f_ffree =3D retvalues;
> - fst->f_namelen =3D retvalues;
> +// fst->f_namelen =3D retvalues;
Wrong. The signature of the statfs method has changed in API 25: instead
of struct statfs, it uses now struct statvfs (which is a standard).
Fields has to be filled as it's appropriate for statvfs, and you have to
take care about f_frsize, otherwise disc usage statistics will be
screwed up in FreeBSD (I guess giving it the same value as that of
f_bsize will do the job).
> ret =3D 0;
> @@ -378,7 +383,7 @@
> state =3D PyThreadState_New(interp);
> - __fuse_process_cmd(f, cmd);
> + fuse_process_cmd(f, cmd);
I didn't know of this, someone could tell if it's appropriate this way?
Anyway, a bit lower there is a __fuse_loop_mt call, I suppose then that
one should be changed to fuse_loop_mt, too.
> fd =3D fuse_mount(mountpoint, kopts);
> - fuse =3D fuse_new(fd, lopts, &op);
> + fuse =3D fuse_new(fd, (struct fuse_args*)0, &op, sizeof (struct fuse_oper=
The fuse_mount() call won't work out this way: now the second arg is not
just a plain string but a fuse_args structure. See the perl patch how
you can assemble such a thing without pain.
Other issues: I/O related methods have now a "struct fuse_file_info"
argument as well. Again, see perl patch.
In fact, I can't understand how you succeeded to get this compiled,
given the signature mismatches.