summaryrefslogtreecommitdiff
path: root/hurd/libfuse.mdwn
blob: 78e960226208e8ad5c32312ef534f1fb7c2fb6b6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag stable_URL]]

`libfuse` is an Hurd-specific implementation of [FUSE](http://fuse.sourceforge.net),
initially written by Stefan Siegl.

The implementation takes advantage of the [[translators|translator]] facilities
of Hurd: this means that applications that implement a FUSE filesystem, when
compiled against libfuse-hurd, become translators to be set with usual [[settrans]]
etc.


# Status

* Only part of the API is implemented
    * lowlevel API not implemented
    * Options handling (`fuse_parse_cmdline` and `fuse_opt_*`) not implemented
    * CUSE lowlevel not supported (compatibility level 29)
* Supports up to the compatibility level 25 (while current libfuse 2.9.x provides 26)
* File I/O is quite slow.


## IRC, freenode, #hurd, 2013-05-31

    <zacts> well the reason I'm asking, is I'm wonder about the eventual
      possibility of zfs on hurd
    <pinotree> no, zfs surely not
    <zacts> *wondering
    <zacts> pinotree: would that be because of license incompatabilities, or
      technical reasons?
    <pinotree> the latter
    <taylanub> It's just a matter of someone sitting down and implementing it
      though, not ?
    <pinotree> possibly
    <braunr> zacts: the main problem seems to be the interactions between the
      fuse file system and virtual memory (including caching)
    <braunr> something the hurd doesn't excel at
    <braunr> it *may* be possible to find existing userspace implementations
      that don't use the system cache (e.g. implement their own)
    <braunr> and they could almost readily use our libfuse version


# Source

[[source_repositories/incubator]], libfuse/master.