1. evhan
  2. chicken-fuse

Commits

evhan  committed d5a6dd0

Remove unnecessary cond-expand

  • Participants
  • Parent commits 34f471e
  • Branches master

Comments (0)

Files changed (2)

File doc/fuse.wiki

View file
 
 ==== Warning
 
-'''This extension is not yet stable.''' Its interface is subject to
-change, and I'd appreciate feedback and suggestions regarding the API.
+'''This extension is not yet stable.''' It may be broken in ways both
+subtle and not so subtle, and its interface is subject to change without
+warning.
 
 ==== Requirements
 
 
 ==== Platform Notes
 
-'''This extension is only officially supported on Linux.''' It has also
-been installed successfully on OpenBSD, FreeBSD and Mac OS X, but tested
-far less thoroughly on those platforms.
+'''This extension is only officially supported on Linux and OpenBSD.'''
+It has also been installed successfully on FreeBSD and Mac OS X, but
+tested far less thoroughly on those platforms.
 
-==== Architecture
+On OpenBSD, each filesystem's main loop is single-threaded.
+
+==== Runtime Structure
 
 Each filesystem is executed in a separate native thread that
 communicates with the (single, shared) CHICKEN runtime via Unix pipe,
-per ([[/egg/concurrent-native-callbacks|concurrent-native-callbacks]]).
-More than one filesystem can be run at a time, but FUSE operations are
+per [[/egg/concurrent-native-callbacks|concurrent-native-callbacks]].
+More than one filesystem run at once, but FUSE operations are
 synchronous across all filesystems so long-running callbacks should be
 avoided.
 
 More importantly, care must be taken not to deadlock the Scheme runtime
-by requesting a filesystem operation from within CHICKEN that will
-itself require a response from CHICKEN, for example by accessing a file
-that's part of a running FUSE filesystem. The easiest way to do this is
-to run each filesystem in a dedicated OS-level process whose sole
+by requesting a filesystem operation from within CHICKEN that itself
+requires a response from CHICKEN, for example by accessing a file that's
+part of a running filesystem. The easiest way to do this is to run each
+filesystem in a more-or-less dedicated OS-level process whose sole
 responsibility is to service FUSE requests.
 
-On OpenBSD, each filesystem's FUSE loop is single-threaded.
-
 === API
 
 <record>filesystem</record>
 numeric values corresponding to the {{statvfs(2)}} struct members of the
 same names.
 
-A resulting {{value}} may be any Scheme object and indicates whether the
+A {{value}} may be any Scheme object and indicates whether the
 filesystem operation was successful. When {{#f}}, the filesystem will
 indicate a nonexistent file ({{ENOENT}}); any other value indicates
 success. Callbacks should signal other types of failures by raising an
 '''{{open:}}''', while '''{{read:}}''' and '''{{write:}}''' should be
 prepared to be called multiple times with diverse {{offset}} values.
 
-<procedure>(filesystem-start! path filesystem) -> undefined</procedure>
+<procedure>(filesystem-start! path filesystem) -> (or #f undefined)</procedure>
 
 Start {{filesystem}} at the given {{path}}.
 
 
 === License
 
-Copyright (c) 2013, 3-Clause BSD.
+Copyright (c) 2013-2014, 3-Clause BSD.

File fuse.scm

View file
   (foreign-lambda c-pointer start_fuse_thread c-pointer))
 
 (define stop-fuse-thread!
-  (cond-expand
-    (openbsd (foreign-lambda bool stop_fuse_thread c-pointer))
-    (else void)))
+  (foreign-lambda bool stop_fuse_thread c-pointer))
 
 (define filesystem-start!
   (let* ((opsize (foreign-type-size "struct fuse_operations"))