These are not all ABI sensitive data structures yet.
Also some space vs tab indentation issues are corrected.
* fuse_new(), and then passed to the file system's init() handler
* which should ensure that the configuration is compatible with the
* file system implementation.
+ *
+ * Note: this data structure is ABI sensitive, new options have to be
+ * appended at the end of the structure
*/
struct fuse_config {
/**
* fuse_file_info argument is NULL.
*/
int nullpath_ok;
+
/**
* Allow parallel direct-io writes to operate on the same file.
*
int parallel_direct_writes;
/**
- * The remaining options are used by libfuse internally and
+ * These 3 options are used by libfuse internally and
* should not be touched.
*/
int show_help;
* concurrently open for the same file. Generally, a client will create one
* file handle per file descriptor, though in some cases multiple file
* descriptors can share a single file handle.
+ *
+ * Note: This data structure is ABI sensitive, new parameters have to be
+ * added within padding/padding2 bits and always below existing
+ * parameters.
*/
struct fuse_file_info {
/** Open flags. Available in open(), release() and create() */
unsigned int keep_cache : 1;
/** Can be filled by open/create, to allow parallel direct writes on this
- * file */
- unsigned int parallel_direct_writes : 1;
+ file */
+ unsigned int parallel_direct_writes : 1;
/** Indicates a flush operation. Set in flush operation, also
maybe set in highlevel lock operation and lowlevel release
* interrupted, and the reply discarded. For example if
* fuse_reply_open() return -ENOENT means, that the release method for
* this file will not be called.
+ *
+ * This data structure is ABI sensitive, on adding new functions these need to
+ * be appended at the end of the struct
*/
struct fuse_lowlevel_ops {
/**
* expected to properly handle the O_APPEND flag and ensure
* that each write is appending to the end of the file.
*
- * - When writeback caching is enabled, the kernel will
+ * - When writeback caching is enabled, the kernel will
* handle O_APPEND. However, unless all changes to the file
* come through the kernel this will not work reliably. The
* filesystem should thus either ignore the O_APPEND flag
* Returning a directory entry from readdir() does not affect
* its lookup count.
*
- * If off_t is non-zero, then it will correspond to one of the off_t
+ * If off_t is non-zero, then it will correspond to one of the off_t
* values that was previously returned by readdir() for the same
* directory handle. In this case, readdir() should skip over entries
* coming before the position defined by the off_t value. If entries