Clang likes to complain when lambdas capture parameters without
actually using them. This patch fixes a couple of such problems in VFS
related os module code.
Issue #4421
Adapts Dir_file_system::open_composite_dirs in a way that it returns "success"
when the leaf node of the path is an empty directory but "lookup failed", as
usual, if one of the other directories on the way to the leaf node is empty.
I couldn't find a technical reason why we used to return "lookup failed" when
only the leaf node was empty.
The commit also adds a test for en empty root directory and empty
sub-directories to the fs_query run script.
Fixes#4198
This patch extends the 'File_system::Status',
'File_system::Directory_entry', and the related 'Vfs' types with
the following additional information:
- Distinction between continuous and transactional files (Node_type)
(issue #3507)
- Readable, writeable, and executable attributes (Node_rwx),
replacing the former 'mode' bits
(issue #3030)
The types 'Node_rwx', 'Node_type' are defined twice,
once for the VFS (vfs/types.h) and once for the 'File_system'
session (file_system_session/file_system_session.h).
Similarly, there is a direct correspondance between
'Vfs::Directory_service::Dirent' and 'File_system::Directory_entry'.
This duplication of types follows the existing pattern of keeping the
VFS and file-system session independent from each other.
Replace the I/O response handler that is passed to the VFS at
construction with an object that is dynamically attached to handles.
This object shall also accept read-ready notifications, and plugins are
encouraged to keep handles awaiting ready-ready notifications separate
from handles that await I/O progress.
Replace the use of handle lists in plugins with handle queues, this
makes the code easier to understand and the ordering of notifications to
the application more explicit.
These changes replace the use of the Post_signal_hook from all VFS
plugins, applications must assume that read-ready and I/O notifications
occur during I/O signal dispatch and use an Io_progress_handler at its
entrypoints to defer response until after signal dispatching.
Fix#3257
The "Vfs::Vfs_handle" type should not contain any public members that
can be initialized by the VFS internally and by the application, so
remove inheritance from the "Genode::list::Element" class. The VFS
plugins must instead use lists of "Vfs::Vfs_handle" sub-classes, the
lifetime of which are always managed by the plugin.
Ref #3036
Reduce the size and forward compatibility of VFS file-system
constructors by passing an object holding accessors for 'Genode::Env',
'Genode::Allocator', response handlers, and the root file-system.
Fix#2742
Add a new 'Vfs_watch_handle' type to the VFS interface. This handle type
will pass a handle context up through the I/O handler to the application
when a notification event occurs.
Watch support implemented for RAM and File_system plugins, all other
file-systems return WATCH_ERR_STATIC by default.
Test at run/fs_rom_update_ram and run/fs_rom_update_fs.
Fix#1934
By letting the 'Dir_file_system' accept an arbitrary 'File_system'
as root directory, we can use the 'Dir_file_system' as a building
block for creating other file-system types.
This patch enables the use of the VFS from VFS plugins by passing a
reference of the root directory to the constructors of file-system
instances. Since it changes the signature of 'Vfs::Dir_file_system',
any code that uses the VFS directly requires an adaptation.
Fixes#2701
The Dir_file_system uses static cast to convert handles from the
application to a plugin local type. For this reason, only the local
handle type may be returned from 'opendir' or 'open'. This fixes the
unexpected behavior when opening directories as files.
Fix#2533
Catch out of RAM and capability exceptions and return error values.
Abort opening a composite directory at Dir_file_system where an
opendir call on any child file-system returns an OUT_OF_RAM or
OUT_OF_CAPS error.
Ref #2642
The patch adjust the code of the base, base-<kernel>, and os repository.
To adapt existing components to fix violations of the best practices
suggested by "Effective C++" as reported by the -Weffc++ compiler
argument. The changes follow the patterns outlined below:
* A class with virtual functions can no longer publicly inherit base
classed without a vtable. The inherited object may either be moved
to a member variable, or inherited privately. The latter would be
used for classes that inherit 'List::Element' or 'Avl_node'. In order
to enable the 'List' and 'Avl_tree' to access the meta data, the
'List' must become a friend.
* Instead of adding a virtual destructor to abstract base classes,
we inherit the new 'Interface' class, which contains a virtual
destructor. This way, single-line abstract base classes can stay
as compact as they are now. The 'Interface' utility resides in
base/include/util/interface.h.
* With the new warnings enabled, all member variables must be explicitly
initialized. Basic types may be initialized with '='. All other types
are initialized with braces '{ ... }' or as class initializers. If
basic types and non-basic types appear in a row, it is nice to only
use the brace syntax (also for basic types) and align the braces.
* If a class contains pointers as members, it must now also provide a
copy constructor and assignment operator. In the most cases, one
would make them private, effectively disallowing the objects to be
copied. Unfortunately, this warning cannot be fixed be inheriting
our existing 'Noncopyable' class (the compiler fails to detect that
the inheriting class cannot be copied and still gives the error).
For now, we have to manually add declarations for both the copy
constructor and assignment operator as private class members. Those
declarations should be prepended with a comment like this:
/*
* Noncopyable
*/
Thread(Thread const &);
Thread &operator = (Thread const &);
In the future, we should revisit these places and try to replace
the pointers with references. In the presence of at least one
reference member, the compiler would no longer implicitly generate
a copy constructor. So we could remove the manual declaration.
Issue #465
This makes '/' and the actual root of VFS distinguishable. A VFS root
may contain one ore more '/' entries for each file system. 'opendir' for
the VFS root opens all file systems via 'open_composite_dir', while
'opendir' for '/' only returns a VFS handle.
Fixes#2569
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
The support has two parts. First, a VFS plugin now gets passed an
I/O-response handler callback on construction, which informs users of the
VFS that an I/O event occurred. This enables, for example, the libC to
check if blocking read can be completed. Further, the VFS file I/O
interface provides now functions for suspendable reads, i.e.,
queue_read() and complete_read().
Besides adapting the components to the use of base/log.h, the patch
cleans up a few base headers, i.e., it removes unused includes from
root/component.h, specifically base/heap.h and
ram_session/ram_session.h. Hence, components that relied on the implicit
inclusion of those headers have to manually include those headers now.
While adjusting the log messages, I repeatedly stumbled over the problem
that printing char * arguments is ambiguous. It is unclear whether to
print the argument as pointer or null-terminated string. To overcome
this problem, the patch introduces a new type 'Cstring' that allows the
caller to express that the argument should be handled as null-terminated
string. As a nice side effect, with this type in place, the optional len
argument of the 'String' class could be removed. Instead of supplying a
pair of (char const *, size_t), the constructor accepts a 'Cstring'.
This, in turn, clears the way let the 'String' constructor use the new
output mechanism to assemble a string from multiple arguments (and
thereby getting rid of snprintf within Genode in the near future).
To enforce the explicit resolution of the char * ambiguity, the 'char *'
overload of the 'print' function is marked as deleted.
Issue #1987
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
When returning early on directory operations, file systems that might
be able to handle the request but come after the current one are not
tried.
Fixes#1400.
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
