Commit Graph

14 Commits

Author SHA1 Message Date
Christian Prochaska
b0935ef9b2 VFS: nonblocking interface
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.

For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.

The most important changes are:

- Directories are created and opened with the 'opendir()' function and the
  directory entries are read with the recently introduced 'queue_read()'
  and 'complete_read()' functions.

- Symbolic links are created and opened with the 'openlink()' function and
  the link target is read with the 'queue_read()' and 'complete_read()'
  functions and written with the 'write()' function.

- The 'write()' function does not wait for signals anymore. This can have
  the effect that data written by a VFS library user has not been
  processed by a file system server yet when the library user asks for the
  size of the file or closes it (both done with RPC functions at the file
  system server). For this reason, a user of the VFS library should
  request synchronization before calling 'stat()' or 'close()'. To make
  sure that a file system server has processed all write request packets
  which a client submitted before the synchronization request,
  synchronization is now requested at the file system server with a
  synchronization packet instead of an RPC function. Because of this
  change, the synchronization interface of the VFS library is now split
  into 'queue_sync()' and 'complete_sync()' functions.

Fixes #2399
2017-08-28 16:49:38 +02:00
Emery Hemingway
1eb37fbe22 VFS: move 'sync' from 'File_system' to 'Directory_service'
The the parent 'Directory_service' interface is reachable from
'Vfs_handle', whereas the 'File_system' interface is not.

Fix #2437
Ref #2422
2017-06-12 14:32:07 +02:00
Norman Feske
29b8d609c9 Adjust file headers to refer to the AGPLv3 2017-02-28 12:59:29 +01:00
Emery Hemingway
ddf3716cff vfs: pass Env and allocator when creating file-systems
Fix #1891
2016-11-08 15:26:31 +01:00
Christian Helmuth
d8c34237bf vfs: default constructor for Dirent and Stat
Fixes #1743
2016-06-28 11:09:27 +02:00
Norman Feske
807be83b1b Remove inconsistent use of 'is_' prefix
Fixes #1963
2016-05-23 15:52:39 +02:00
Emery Hemingway
1d301e9c14 lib/vfs: consistent device and inode enumeration
Issue #1751
2016-04-25 10:47:54 +02:00
Emery Hemingway
b8e52189d5 lib/vfs: new permissions errors
New errors STAT_ERR_NO_PERM, DIRENT_ERR_NO_PERM, and READLINK_NO_PERM to
distinguish lookup errors from permissions or other errors.

Issue #1751
2016-04-25 10:47:54 +02:00
Emery Hemingway
82a7799638 lib/vfs: pass handle allocator to open(...)
Opening a VFS handle previously involved allocating from the global heap
at each VFS file system. By amending open with an allocator argument,
dynamic allocation can be partitioned.

A new close method is used to deallocate open handles.

Issue #1751
Issue #1891
2016-04-11 12:56:54 +02:00
Emery Hemingway
1d92631ef0 VFS, File_system: Not_empty
Unlink returns an error for non-empty directories when the backend does
not support recursive unlinking.

Fixes #1750
2015-11-29 18:17:05 +01:00
Emery Hemingway
1779a0511b vfs: add new error codes
The codes are OPEN_ERR_NAME_TOO_LONG, OPEN_ERR_NO_SPACE, and
FTRUNCATE_ERR_NO_SPACE.

Issue #1693
2015-10-06 12:18:51 +02:00
Emery Hemingway
f996697fd5 VFS: local ram_fs instances
Move FS Node implementations from server/ram_fs to include/ram_fs.
Support embedded ram_fs instances in VFS configurations using <ram/>.
Add 'no space' handling to VFS symlink ops.

Fixes #1635
2015-08-21 10:58:40 +02:00
Alexander Boettcher
8b8c2713ae vfs: use 64bit for file offset and size
Fixes #1246
2014-10-10 13:02:28 +02:00
Norman Feske
ca971bbfd8 Move repositories to 'repos/' subdirectory
This patch changes the top-level directory layout as a preparatory
step for improving the tools for managing 3rd-party source codes.
The rationale is described in the issue referenced below.

Issue #1082
2014-05-14 16:08:00 +02:00