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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
[[!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 the compatibility level 25 and 26, up to libfuse 2.6.x
* 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
## IRC, freenode, #hurd, 2013-10-01
<pinotree> our libfuse implementation is still basic atm (there's a wiki
page about it)
<alsuren> okay... talk to me about FUSE
<pinotree> even with the improvements i have in my public branch, it still
cannot do real-world fs'es
<alsuren> okay, so you're the person to ask about FUSE
<alsuren> it strikes me that HURD not having FUSE support is a bit of an
architectural oversight
<pinotree> i'm not sure what's your point about fuse, since what fuse on
linux (and not only) does is done *natively* by the hurd
<alsuren> exactly
<pinotree> all of the hurd filesystems (which are just a type of servers)
run in userspace already
<alsuren> so FUSE should Just Work
<pinotree> well no
# Source
[[source_repositories/incubator]], libfuse/master.
|
