* Prototypes for fuse_new(3), fuse_mount(3), and fuse_unmount(3) now
matches to the original fuse interface.
* Add fuse_daemonize(3): needs to have a different prototype,
otherwise we can't use puffs_daemon(3).
* Remove fuse_setup(3) and fuse_teardown(3). These obsolete functions
has already been removed from the original interface.
* fuse_main(3) now supports the following command-line options
compatible with the original fuse:
-h, --help print help message
-V, --version print library version (currently does nothing)
-d, -o debug enable debug output (PUFFS_FLAG_OPDUMP), implies -f
-f foreground mode
-s single threaded mode (always enabled for now)
-o fsname=NAME explicitly set the name of the file system
* fuse_main(3) now daemonizes the process by default. This is for the
compatibility with the original fuse.
In puffs "create" and "open" are two separate operations with
atomicity achieved by locking the parent vnode. In fuse, on the other
hand, "create" is actually a create-and-open-atomically and the open
flags (O_RDWR, O_APPEND, ...) are passed via fi.flags. So the only way
to emulate the fuse semantics is to open the file with dummy flags and
then immediately close it.
You might think that we could simply use fuse->op.mknod all the time
but no, that's not possible because most file systems nowadays expect
op.mknod to be called only for non-regular files and many don't even
support it.
around this by returning ENOSPC in case of a short write to avoid protocol
errors. This change is based on problem analysis provided by Antti Kantee.
This fixes PR lib/45129 by myself.
Ok, ok, a few more words about it: stop holding puffs_cc as a holy
value and passing it around to almost every possible place (popquiz:
which kernel variable does this remind you of?). Instead, pass
the natural choice, puffs_usermount, and fetch puffs_cc via
puffs_cc_getcc() only in routines which actually need it. This
not only simplifies code, but (thanks to the introduction of
puffs_cc_getcc()) enables constructs which weren't previously sanely
possible, say layering as a curious example.
There's still a little to do on this front, but this was the major
fs interface blast.
servers. Calling daemon() (i.e. fork()ing) inside a library can
cause nice surprises for e.g. threaded programs. As discussed with
Greg Oster & others.
instead of depending if a lock was succesfully acquired. Also, add
a comment explaining why it is such complex (for all I could guess).
* replace err()'s with abort()
* replace some abort()'s by returning failure
