From: Csaba H. <csa...@cr...> - 2006-01-29 00:31:10
|
Hi, On 2006-01-28, Simon Barner <barner@FreeBSD.org> wrote: > I'd also be happy with a document describing the various FUSE APIs. I brows= > ed > your website, and did some research, but I could not find anything that wou= > ld > 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): http://fuse4bsd.creo.hu/doc/html_chunked_out/Quickstart.html#hd001005 If you are porting Python bindings, you might be particularly interested in my preliminary Perl binding API upgrade: http://creo.hu/pipermail/fuse4bsd-devel/2006-January/000117.html 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 > //@+others > //@+node:includes > +#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; > } >=20 > - ret =3D df(dh, PyString_AsString(o0), PyInt_AsLong(o1));=09 > + /* XXX */ > + ret =3D df(dh, PyString_AsString(o0), PyInt_AsLong(o1), 0);=09 >=20 Fine, too. > out_decref: > Py_DECREF(o0); > @@ -345,7 +350,7 @@ > fst->f_bavail =3D retvalues[3]; > fst->f_files =3D retvalues[4]; > fst->f_ffree =3D retvalues[5]; > - fst->f_namelen =3D retvalues[6]; > +// fst->f_namelen =3D retvalues[6]; >=20 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; > =20 > @@ -378,7 +383,7 @@ > PyEval_AcquireLock(); > state =3D PyThreadState_New(interp); > PyThreadState_Swap(state); > - __fuse_process_cmd(f, cmd); > + fuse_process_cmd(f, cmd); > PyThreadState_Clear(state); > PyThreadState_Swap(NULL); 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. >=20 > 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= > ations)); 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. HTH. Regards, Csaba |
From: Csaba H. <csa...@cr...> - 2006-01-29 07:48:09
|
On 2006-01-29, Csaba Henk <csa...@cr...> wrote: > to FreeBSD, but in fact, it's platform dependent, any API upgrader can Duh. *in*dependent, of course. Csaba |