Python bindings

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Python bindings

Johan Rydberg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm reworking the python bindings a bit, adopting it to use the
lowlevel (inode based) interface instead of working with full path
names.  I need this for a project of mine.

Anyway, I came to think, that it might be better to provide an
interface in the lines of the API that SULF provides.  Instead
of having one large FileSystem class with all the operations you
split it into several classes;

  FileSystem
   |
   +--- ...

  Node
   |
   +--- DirNode
   |
   +--- FileNode
          |
          +-- MutableNode
          |
          +-- ...

I suppose this can be better if you plan to write any more complex
filesystem.

You can browse the SULF hierarchy here:

  http://arg0.net/users/vgough/sulf/hierarchy.html

Any comments?

~j

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFC8Paa3CqIy3K3X2ERAlBVAJ9pUNop4LE51N6vcKMcBi9a7Krg1QCg0dnc
dfKRpak7d+HyF5H9sYI4Z14=
=GbQP
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python bindings

Valient Gough
On Wednesday 03 August 2005 18:53, Johan Rydberg wrote:

> I'm reworking the python bindings a bit, adopting it to use the
> lowlevel (inode based) interface instead of working with full path
> names.  I need this for a project of mine.
>
> Anyway, I came to think, that it might be better to provide an
> interface in the lines of the API that SULF provides.  Instead
> of having one large FileSystem class with all the operations you
> split it into several classes;

> Any comments?

Hi,

I don't know much python [1], so I can't say much about the technical fit.  
The split of the interfaces into mutable and non-mutable types started as an
experiment because the previous interfaces were getting too cluttered.  I
think they are much cleaner this way, but that doesn't mean you couldn't come
up with something even better! :-)

The split is also used inside the Reactor class, which handles dispatching of
kernel requests.  After it looks up a Node, it tries to cast it to the
appropriate type for the operation.  For example if a Write operation is
being performed, then it tries to cast to MutableFileNode.  If the cast
fails, then that means a write is not allowed.  Actually that's a bad example
because Open should have failed when it was requested to open for write, but
that's the idea anyway.

Does python have the information necessary to do dynamic casts like this at
runtime? If not then the distinction may not help.

regards,
Valient

[1] my only tiny python module is a Latex math renderer for the Trac project
management system: http://trac-hacks.swapoff.org/wiki/LatexFormulaMacro

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python bindings

Johan Rydberg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Valient Gough <[hidden email]> writes:

> The split is also used inside the Reactor class, which handles dispatching of
> kernel requests.  After it looks up a Node, it tries to cast it to the
> appropriate type for the operation.  For example if a Write operation is
> being performed, then it tries to cast to MutableFileNode.  If the cast
> fails, then that means a write is not allowed.  Actually that's a bad example
> because Open should have failed when it was requested to open for write, but
> that's the idea anyway.
>
> Does python have the information necessary to do dynamic casts like this at
> runtime? If not then the distinction may not help.

It doesn't really support that, not to my knowledge at least. What is
possible, though, to check if an instance has the "write" method
implemented.  If not, it probably isn't a mutable node.

A more technical detail.  Do you keep a simple table of ino->node
mappings, and if so, when do you know to remove a node from the map?
Whenever release/forget is invoked on the node?

~j
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFC8TpW3CqIy3K3X2ERAlfTAJ9GXFHRNJj90hTUGqUYrDFtn3qSkQCgljBJ
ISQncGSBt9OtkXm2e0ZiqYM=
=HHSB
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python bindings

Valient Gough
On Wednesday 03 August 2005 23:42, Johan Rydberg wrote:

> A more technical detail.  Do you keep a simple table of ino->node
> mappings, and if so, when do you know to remove a node from the map?
> Whenever release/forget is invoked on the node?

Yeah, Fuse/NodeMap is where I implement the inode->Node mapping.  In sulf,
when nodes are created they don't have any inode number associated with them.  
Certain fuse operations (like lookup) will require an inode to be associated
if there isn't already one.  The lookup count starts as 1 and then whenever
you get a lookup for a node, the count is incremented.  A forget message
specifies how many lookups to remove (nlookup), and when it reaches 0 then
the client can forget about the inode -> node mapping.

But you're talking about implementing on top of the fuse_lowlevel interface,
which I haven't used.  It looks like you need to do lookup count accounting
(since fuse_ll_operations.forget specifies nlookup arg), but how does one
know when they should increment the local lookup count for a node?

For sulf, I figured it out by seeing what libfuse and the kernel do, but maybe
fuse_lowlevel will need that to be documented since it is part of the
lowlevel interface..

regards,
Valient




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python bindings

Miklos Szeredi
> Certain fuse operations (like lookup) will require an inode to be associated
> if there isn't already one.  The lookup count starts as 1 and then whenever
> you get a lookup for a node, the count is incremented.  A forget message
> specifies how many lookups to remove (nlookup), and when it reaches 0 then
> the client can forget about the inode -> node mapping.
>
> But you're talking about implementing on top of the fuse_lowlevel interface,
> which I haven't used.  It looks like you need to do lookup count accounting
> (since fuse_ll_operations.forget specifies nlookup arg), but how does one
> know when they should increment the local lookup count for a node?

When the lookup() method is called.

The kernel interface and the lowlevel API are semantically equivalent.

> For sulf, I figured it out by seeing what libfuse and the kernel do,
> but maybe fuse_lowlevel will need that to be documented since it is
> part of the lowlevel interface..

Yeah.  I leave documentation to the last minute, maybe a miracle
happens, and someone does it instead of me.  Hint, hint ;)

Miklos


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python bindings

Johan Rydberg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miklos Szeredi <[hidden email]> writes:

>> For sulf, I figured it out by seeing what libfuse and the kernel do,
>> but maybe fuse_lowlevel will need that to be documented since it is
>> part of the lowlevel interface..
>
> Yeah.  I leave documentation to the last minute, maybe a miracle
> happens, and someone does it instead of me.  Hint, hint ;)

I started hacking on some docs for the communication between the
kernel and libfuse.  They should be somewhere in the archive, I
suppose.  But the docs were written in TexInfo, which you didn't like
IIRC.  :)    Maybe it can be useful anyway.

~j

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFC8g5E3CqIy3K3X2ERAuv0AKCCe+4QUSl5AC6pJ1lvR2f5h4JdZACeNkyN
PuWSaTXxMhx/D/qVRp8yRY4=
=ffBf
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python bindings

Miklos Szeredi
> I started hacking on some docs for the communication between the
> kernel and libfuse.  They should be somewhere in the archive, I
> suppose.  But the docs were written in TexInfo, which you didn't like
> IIRC.  :)

Didn't I?  I can't remember.

I certainly don't have any problems with it now :)

> Maybe it can be useful anyway.

Can you dig it out?

Thanks,
Miklos


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Python bindings

Johan Rydberg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miklos Szeredi <[hidden email]> writes:

>> Maybe it can be useful anyway.
>
> Can you dig it out?

I couldn't find the source of it, probably lost it in my HD crash.
But I found the mail, and the link still works;

  http://sourceforge.net/mailarchive/message.php?msg_id=10005566

~j
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFC8h2b3CqIy3K3X2ERAuF6AJ9z3+hiB2cGCTe9g4jXAOyJpfpeMACfbe+e
mi71gngTgU2IEGYewDz1Mk0=
=RvpT
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

documentation (was Re: Python bindings)

Valient Gough
In reply to this post by Miklos Szeredi
On Thursday 04 August 2005 14:41, Miklos Szeredi wrote:

> > but how does one know when they should increment the local lookup count
> > for a node?
>
> When the lookup() method is called.

Yes, that's the easy one.  But what about the methods responsible for
initializing nlookup to 1 (mknod, mkdir, symlink, link).  If you didn't count
those then the lookup count would be off by one.

Also, someone using the low-level interface needs to realize that if the
kernel returns a failure message when they send a response from any of those
five methods (including lookup()), then they need to decrement the nlookup
count (like reply_entry() in libfuse).

I think this is tricky just because it is almost completely hidden.  There is
a "nlookup" parameter in the forget() method, but that's it - like an
ice-burg.  It isn't that I'm complaining, I think it works fine, but it
confused me when I wrote a low-level driver and I'm sure I won't be the last
one. :-)

> Yeah.  I leave documentation to the last minute, maybe a miracle
> happens, and someone does it instead of me.  Hint, hint ;)

Sounds like a good plan.  For long descriptions, such as how to properly
account for nlookup using the lowlevel interface, that's probably too much to
insert into fuse_lowlevel.h.  Are you interested in a doxygen build of
documentation, or online wiki, or a set of files in the doc/ dir (or whatever
you can get)?

Valient


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
fuse-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/fuse-devel