Re: [fuse-devel] Re: low-level API info?

[Nix <ni...@es...>]

On Sat, 21 Jan 2006, Csaba Henk gibbered uncontrollably:
> On 2006-01-21, Bjorn Lalin <bjo...@gm...> wrote:
>> Hello, I was just wondering if there is any more information available on
>> the low-level API?
> 
> More than what? :)

Quite so. It doesn't do much. Hence *low level*. :)

> examples/hello_ll.c is a simple fuse_lowlevel application, lib/fuse.c
> (ie., the hi-level API) is a somewhat more complex one. Reading through
> these should help (yet there might be other means to that end). At
> least, hello_ll.c takes five minutes to understand, if you are somewhat
> familiar with FUSE.

Certainly the fuse_lowlevel_ops/fuse_reply stuff is easy to grasp.

I had to puzzle over the session/channel based stuff, though, and I'm
still not entirely sure what its intended use is: I mean, what's the
multiple-channels-per-session stuff for? To allow you to implement the
equivalent of fuse_session_loop_mt() yourself?

(If so, I *can* see the use of it, but it's hardly obvious. :) )

>> What it brings in addition to the other one?
> 
> It's a close match to the userspace/kernel messaging interface. Direct
> nodeid based file access, and so on. I think it's the most useful for
> language binding writers, who can use it to implement the path based API
> using native/standard data types of their language.

It's also useful if you need to write something that is trying to emulate
a real POSIX filesystem very closely; if you *already* have close mappings
to the ideas of inodes and directory entries all neatly separated, it seems
both silly and difficult *not* to use the low-level interface; the high-
level one would just tangle them back together again :)

There's no question which is better for quick hacks though. Most FUSE
filesystems probably don't care about representing inode numbering
themselves!

-- 
`Everyone has skeletons in the closet.  The US has the skeletons
 driving living folks into the closet.' --- Rebecca Ore