The fds in O_APPEND state may have changed by the child. The local seek
state needs to be valid/current for the next to be forked child, which seek
state is set by File_descriptor_allocator::generate_info().
Issue #3991
There is a type mismatch as in the FreeBSD contrib code the type of the
request is 'unsigned long'. So far, only I/O controls where the request
falls into the signed range where used and this was not a problem.
Some of the SNDCTL requests, however, have the bit set.
Fixes#3887.
This is important to issue sync requests for written-to files.
As the closing must be performed by an atexit handler, it happens at a
time _after_ libc plugins are destructed. Consequently an FD allocated
by such a plugin results in a close error, which in turn, does not
destruct the FD. We ultimatedly end up in an infinte loop of
re-attempting the close. For this reason, the patch changes 'close' to
be robust against this special case.
This is generally not a problem because libc plugins are phased out.
However, at present, the libc_noux plugin is still important. With the
changed 'close' in place, there occurred an error message "Error: close:
close not implemented" at the exit of each noux program. This patch
removes the error printing from the libc plugin mechansim to avoid this
noise. The error messages are not important anyway because the
deprecation of the libc plugin interface.
Issue #3578
- Close FDs marked with the close-on-execve flag
(needed for 'make', which sets the flag for the pipe-in
FD of forked children)
- Update binary name on execve to use as ROM for subsequent fork
- Enable vfork as an alias for fork (needed by make)
- Purge line buffers for output streams during execve because they
may be allocated at the allocation heap, which does not survive
the execve call.
- Consider short-lived processes that may exit while the parent still
blocks in the fork call.
With these changes, the website generator of genodians.org works without
the need for the Noux runtime.
Issue #3578
fd > FD_SETSIZE cannot use 'select' or 'poll' within our libc.
Therefore, we added a bit allocator in order to allocate fd < FD_SETSIZE
(1024).
fixes#3568
This patch implements 'execve' in Genode's libc.
The mechanism relies on the dynamic linker's ability to replace the
loaded binary while keeping crucial libraries - in particular the libc -
intact. The state outside the libc is wiped. For this reason, all libc
internal state needed beyond the 'execve' call must be allocated on a
heap separate from the application-owned malloc heap. E.g.,
libc-internal file-descriptor objects must not be allocated or refer to
any memory object allocated from the malloc heap.
Issue #3481
The libc already supports the configuration of 'stdin', 'stdout', and
'stderr' using '<libc>' config attributes. This patch equips the libc
with the additional ability to pre-initialize any other file descriptor.
A file descriptor is configured as follows:
<config>
...
<libc ...>
<fd id="3" path="/dev/log" writeable="yes" readable="no" seek="10"/>
...
</libc>
</config>
Furthermore, this patch moves the FD initialization code from the VFS
plugin to the libc kernel initialization because opening the FDs
depends on 'malloc' ('strdup'), which should not be used at early
'Libc::Kernel' initialization time.
Issue #3478
This patch replaces the former use of an Allocator_avl with the Id_space
utility, which is safer to use and allows for the iteration of all
elements. The iteration over open file descriptors is needed for
implementing 'fork'.
Issue #3478
Remove getaddrinfo and freeaddrinfo from the Libc::Plugin and get rid of
the extra libc_resolv library. Remove getaddrinfo/freeaddrinfo symbol
hiding patch for FreeBSD sources. Remove libc_resolv from Makefiles and
run scenarios.
Fix#2273
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
This patch moves the VFS file-system factory to a separate vfs library
that is independent from libc. This enables libc-less Genode programs to
easily use the VFS infrastructure.
Fixes#1561
These file systems are provided on-demand by loading a shared library
when the fstab node is traversed. By convention this library is named
after the file system it provides. For example a file system that
provides a 'random' file system node is called 'vfs_random.lib.so'. It
is still possible to give the the node another name in the vfs. The
following code snippts illustrates this matter:
! [...]
! <config>
! <libc>
! <vfs>
! <dir name="dev"> <jitterentropy name="random"/> </dir>
! </vfs>
! </libc>
! </config>
! [...]
Here the jitterentropy file system, implemented in
'vfs_jitterentropy.lib.so' provides a file system node named 'random'
in the 'dev' directory. When traversing the vfs section the libc will
try to load 'vfs_jitterentropy.lib.so' but programs may access the
file system only via '/dev/random'.
Fixes#1240.
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
