mirror of
https://github.com/genodelabs/genode.git
synced 2025-01-22 20:38:09 +00:00
Spelling fixes reported by m-stein and ssumpf
This commit is contained in:
parent
04969dcf69
commit
de162831cb
@ -62,9 +62,8 @@ former one naturally builds upon the just recently added file-system interface.
|
|||||||
Furthermore, we decided to defer the live CD until July as we realized that we
|
Furthermore, we decided to defer the live CD until July as we realized that we
|
||||||
first need to overhaul low-level components such as USB before the new live
|
first need to overhaul low-level components such as USB before the new live
|
||||||
system can be expected to work as intended. Also, some of the scenarios we want
|
system can be expected to work as intended. Also, some of the scenarios we want
|
||||||
to present depend on framework features that are just introduced with the
|
to present depend on framework features just introduced with the current release,
|
||||||
current release, in particular the file-system infrastructure and the media
|
in particular the file-system infrastructure and the media capabilities.
|
||||||
capabilities.
|
|
||||||
|
|
||||||
|
|
||||||
Re-approaching the Linux device-driver environment
|
Re-approaching the Linux device-driver environment
|
||||||
@ -148,34 +147,34 @@ is that finding the right mix of reimplementation, slight modification, and
|
|||||||
reuse is a matter of sure instinct of the DDE developer.
|
reuse is a matter of sure instinct of the DDE developer.
|
||||||
|
|
||||||
Another way to put it is defining the problem as the search in an optimization
|
Another way to put it is defining the problem as the search in an optimization
|
||||||
space for the economically most sensible solution. The optimization criterion
|
space for the economically most sensible solution. The optimization criterion we
|
||||||
we set out to maximize is the ratio of feature code (the actual driver, no DDE
|
set out to maximize is the ratio of feature code (the actual driver, no DDE nor
|
||||||
nor glue) to the number of lines of code that must be manually maintained. To
|
glue) to the number of lines of code that must be manually maintained. To give
|
||||||
give the order of magnitude of the code we speak of, the traditional Linux DDE
|
the order of magnitude of the code we speak of, the traditional Linux DDE
|
||||||
including the support for NIC, USB, and sound is comprised of more than 350.000
|
including the support for NIC, USB, and sound is comprised of more than 350.000
|
||||||
lines of code. The portion of modified or custom written code (code that must
|
lines of code. The portion of modified or custom written code (code that must be
|
||||||
be manually maintained) is more than 40.000 lines of code. Given this
|
manually maintained) is more than 40.000 lines of code. Given this complexity,
|
||||||
complexity, we found us hesitant to update the code to newer kernel versions.
|
we found us hesitant to update the code to newer kernel versions. The
|
||||||
The engineering labour of such an update is significant yet not much rewarding
|
engineering labour of such an update is significant yet not much of a rewarding
|
||||||
work. Apart from the burden of managing a piece of software that complex, our
|
work. Apart from the burden of managing a piece of software that complex, our
|
||||||
confidence in the classical Linux DDE approach slipped further with each
|
confidence in the classical Linux DDE approach slipped further with each
|
||||||
debugging session that involved Linux DDE. In our experience, Linux DDE still
|
debugging session that involved Linux DDE. In our experience, Linux DDE still
|
||||||
significantly deviates from the semantics of the Linux kernel but in subtle
|
significantly deviates from the semantics of the Linux kernel but in subtle
|
||||||
ways. Often problems go unnoticed until a driver uses a kernel API in a
|
ways. Often problems go unnoticed until a driver uses a kernel API in a
|
||||||
slightly unusual way. For example, a driver calling 'udelay()' from the interrupt
|
slightly unusual way. For example, a driver calling 'udelay()' from the interrupt
|
||||||
handler. The sheer complexity of the code base can make localizing such issues
|
handler. The sheer complexity of the code base can make tracking down such issues
|
||||||
a painful experience. This is further amplified by the existence of certain
|
a painful experience. This is further amplified by the existence of certain
|
||||||
invariants provided by the Linux kernel but absent in the Linux DDE. One
|
invariants provided by the Linux kernel but absent in the Linux DDE. One
|
||||||
particular source of trouble is the control flow in the event of an interrupt.
|
particular source of trouble is the control flow in the event of an interrupt.
|
||||||
In the Linux kernel, the interrupt handler can make the assumption that no code
|
Within the Linux kernel, the interrupt handler can make the assumption that no
|
||||||
of the interrupted CPU can be executed until the interrupt handler returns. In
|
code of the interrupted CPU can be executed until the interrupt handler returns.
|
||||||
contrast, Linux DDE models interrupts as independent threads and assumes that
|
In contrast, Linux DDE models interrupts as independent threads and assumes that
|
||||||
all code is multi-processor safe. Consequently the control flows of the driver
|
all code is multi-processor safe. Consequently the control flows of the driver
|
||||||
executed in the Linux kernel and the same driver executed in Linux DDE differs
|
executed in the Linux kernel and the same driver executed in Linux DDE differs
|
||||||
in subtle ways, leading to the worst of all bugs namely race conditions.
|
in subtle ways, leading to the worst of all bugs namely race conditions.
|
||||||
|
|
||||||
While our focus shifted away from the classical Linux DDE, we discovered the
|
While our focus shifted away from the classical Linux DDE, we discovered the
|
||||||
beauty of creating extremely tight device driver environments. In contrast to
|
beauty of creating extremely tight device-driver environments. In contrast to
|
||||||
the Linux DDE, which tried to be useful for a large range of driver classes on
|
the Linux DDE, which tried to be useful for a large range of driver classes on
|
||||||
the cost of becoming complex, we created new slim DDEs for single drivers or a
|
the cost of becoming complex, we created new slim DDEs for single drivers or a
|
||||||
strictly outlined class of drivers. One example is the DDE for iPXE networking
|
strictly outlined class of drivers. One example is the DDE for iPXE networking
|
||||||
@ -200,13 +199,13 @@ multiple pseudo-thread contexts using cooperative scheduling.
|
|||||||
The result is more than convincing for us. With a DDE of less than 4.000 lines
|
The result is more than convincing for us. With a DDE of less than 4.000 lines
|
||||||
of code, we have become able to use the unmodified Linux-3.2 USB stack, which
|
of code, we have become able to use the unmodified Linux-3.2 USB stack, which
|
||||||
comprises more than 60.000 lines of code. Only 3 lines had to be modified. In
|
comprises more than 60.000 lines of code. Only 3 lines had to be modified. In
|
||||||
contrast to Linux DDE, the 4.000 lines of custom-written DDE code are
|
contrast to Linux DDE, the 4.000 lines of custom-written DDE code are relatively
|
||||||
relatively easy to comprehend. For the most of the functions provided by the
|
easy to comprehend. For most of the functions provided by the DDE, the
|
||||||
DDE, the implemented semantics is a rigid subset of the original functionality
|
implemented semantics are a rigid subset of the original functionality as found
|
||||||
as found in the Linux kernel. Apparently the knowledge about the usage patterns
|
in the Linux kernel. Apparently the knowledge of function usage patterns in a
|
||||||
of the functions in the particular driver allows for vast simplifications.
|
particular driver allows for vast simplifications. Given our self-imposed rule
|
||||||
Given our self-imposed rule to not modify 3rd-party code, we expect that future
|
to not modify 3rd-party code, we expect that future updates to new Linux kernel
|
||||||
updates to new Linux kernel versions will pose much less of a burden.
|
versions will pose much less of a burden.
|
||||||
|
|
||||||
With our current approach of creating rigidly tailored DDEs, we are convinced
|
With our current approach of creating rigidly tailored DDEs, we are convinced
|
||||||
to have found a healthy balance between the manual effort needed to create and
|
to have found a healthy balance between the manual effort needed to create and
|
||||||
@ -324,9 +323,9 @@ libraries, executable binaries, and configuration data are passed to child
|
|||||||
subsystems as ROM modules. But in contrast to core's ROM modules, this
|
subsystems as ROM modules. But in contrast to core's ROM modules, this
|
||||||
information may be dynamic in nature. For example, the configuration of the
|
information may be dynamic in nature. For example, the configuration of the
|
||||||
audio mixer may change at any time during the lifetime of the mixer. Also
|
audio mixer may change at any time during the lifetime of the mixer. Also
|
||||||
executable binaries may change in the event of system updates. Providing the
|
executable binaries may change in the event of system updates. Enabling the
|
||||||
system with the ability to respond to such changes is crucial to the use of
|
system to respond to such changes is crucial the use of Genode as
|
||||||
Genode as general-purpose OS.
|
general-purpose OS.
|
||||||
|
|
||||||
For existing users of the ROM session interface, there is nothing to consider.
|
For existing users of the ROM session interface, there is nothing to consider.
|
||||||
API compatibility is maintained. However, by installing a signal handler using
|
API compatibility is maintained. However, by installing a signal handler using
|
||||||
@ -382,7 +381,7 @@ supplying the new sub system as a single binary blob only. The server used to
|
|||||||
implement heuristics and functionality for dealing with different kinds of
|
implement heuristics and functionality for dealing with different kinds of
|
||||||
blobs such as ELF images or TAR archives. This has been replaced by a
|
blobs such as ELF images or TAR archives. This has been replaced by a
|
||||||
session-local ROM service, which can be equipped with an arbitrary number of
|
session-local ROM service, which can be equipped with an arbitrary number of
|
||||||
ROM modules supplied by the loader client prior starting the new sub system.
|
ROM modules supplied by the loader's client prior starting a new subsystem.
|
||||||
Even though the TAR support has been removed, a separate instance of the
|
Even though the TAR support has been removed, a separate instance of the
|
||||||
'tar_rom' service can be used within the subsystem to provide the formerly
|
'tar_rom' service can be used within the subsystem to provide the formerly
|
||||||
built-in functionality.
|
built-in functionality.
|
||||||
@ -393,7 +392,7 @@ nitpicker session of the loaded subsystem. The corresponding source code
|
|||||||
can be found at 'os/src/test/loader/'. The second example at
|
can be found at 'os/src/test/loader/'. The second example at
|
||||||
'os/run/dynamic_config_loader.run' shows how the concept of dynamic ROM
|
'os/run/dynamic_config_loader.run' shows how the concept of dynamic ROM
|
||||||
sessions can be combined with the loader. As demonstrated by this example,
|
sessions can be combined with the loader. As demonstrated by this example,
|
||||||
ROM images used by the loaded sub system can be updated at runtime by the
|
ROM images used by the loaded subsystem can be updated at runtime by the
|
||||||
client of the loader session.
|
client of the loader session.
|
||||||
|
|
||||||
|
|
||||||
@ -422,10 +421,10 @@ rather than individual file objects.
|
|||||||
In-memory file system
|
In-memory file system
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
As reference implementation of the new interface, there is the new 'ram_fs'
|
As reference implementation of the new interface, a new 'ram_fs' service can be
|
||||||
service at 'os/src/server/ram_fs'. It stores sparse files in memory. At the
|
found at 'os/src/server/ram_fs'. It stores sparse files in memory. At startup
|
||||||
startup, 'ram_fs' is able to populate the file-system content with directories,
|
time, 'ram_fs' is able to populate the file-system with directories, ROM
|
||||||
ROM modules, and inline data as specified in its configuration.
|
modules, and inline data as specified in its configuration.
|
||||||
|
|
||||||
Access to the file system can be tailored for each session depending on the
|
Access to the file system can be tailored for each session depending on the
|
||||||
session's label. By default, no permissions are granted to any session.
|
session's label. By default, no permissions are granted to any session.
|
||||||
@ -457,7 +456,7 @@ The following configuration illustrates the way of how to express policy.
|
|||||||
The '<content>' sub node of the '<config>' node provides a way to pre-populate
|
The '<content>' sub node of the '<config>' node provides a way to pre-populate
|
||||||
the file system with directories and files. Note that '<dir>' nodes can be
|
the file system with directories and files. Note that '<dir>' nodes can be
|
||||||
arbitrarily nested. Files can be loaded from the ROM service. By adding the
|
arbitrarily nested. Files can be loaded from the ROM service. By adding the
|
||||||
optional 'at' attribute to a '<rom>' node, the file name can be defined
|
optional 'as' attribute to a '<rom>' node, the file name can be defined
|
||||||
independently from the ROM module name. In addition to creating files from
|
independently from the ROM module name. In addition to creating files from
|
||||||
ROM modules, files can be created from data specified directly as part of the
|
ROM modules, files can be created from data specified directly as part of the
|
||||||
configuration using '<inline>' nodes. The content of such nodes is used as
|
configuration using '<inline>' nodes. The content of such nodes is used as
|
||||||
@ -498,7 +497,7 @@ File-system plugin for the C runtime
|
|||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
To enable libc-using programs to access the new file-system interface, there is
|
To enable libc-using programs to access the new file-system interface, there is
|
||||||
the new libc plugin at 'libports/src/lib/libc_fs'. Using this plugin, files
|
a new libc plugin at 'libports/src/lib/libc_fs'. Using this plugin, files
|
||||||
stored on a native Genode file system can be accessed using the traditional
|
stored on a native Genode file system can be accessed using the traditional
|
||||||
POSIX file API.
|
POSIX file API.
|
||||||
|
|
||||||
@ -548,7 +547,7 @@ work is required anyway.
|
|||||||
|
|
||||||
On the other hand, there are 3rd-party applications that would be nice to
|
On the other hand, there are 3rd-party applications that would be nice to
|
||||||
reuse as is without any manual patching work, for example the libSDL-based
|
reuse as is without any manual patching work, for example the libSDL-based
|
||||||
'avplay' or the muPDF example application. To ease the integration of such
|
'avplay' or the muPDF application. To ease the integration of such
|
||||||
programs into Genode setups, we added the new 'config_args' library. At the
|
programs into Genode setups, we added the new 'config_args' library. At the
|
||||||
startup of the program, this library inspects the config node for arguments and
|
startup of the program, this library inspects the config node for arguments and
|
||||||
fills the argv structure to be passed to the 'main()' function.
|
fills the argv structure to be passed to the 'main()' function.
|
||||||
@ -668,7 +667,7 @@ supported. We will complement the coverage of support as needed.
|
|||||||
|
|
||||||
:SDL audio support:
|
:SDL audio support:
|
||||||
|
|
||||||
The new libSDL audio backend enables the use of Genode's audio-session
|
The new libSDL audio back end enables the use of Genode's audio-session
|
||||||
interface from SDL applications. This way, SDL programs can be combined
|
interface from SDL applications. This way, SDL programs can be combined
|
||||||
with audio drivers as well as with the mixer component.
|
with audio drivers as well as with the mixer component.
|
||||||
|
|
||||||
@ -679,7 +678,7 @@ SDL application:
|
|||||||
! <sdl_audio_volume value="100"/>
|
! <sdl_audio_volume value="100"/>
|
||||||
! </config>
|
! </config>
|
||||||
|
|
||||||
Note that the SDL audio backend does respond to configuration changes at
|
Note that the SDL audio back end does respond to configuration changes at
|
||||||
run time. By supplying the config dynamically rather than via a static
|
run time. By supplying the config dynamically rather than via a static
|
||||||
file, the audio volume may get updated while the SDL application is running.
|
file, the audio volume may get updated while the SDL application is running.
|
||||||
|
|
||||||
@ -738,7 +737,7 @@ player. It consists of the following pieces.
|
|||||||
interfaces, in particular the audio mixer, framebuffer and input drivers, but
|
interfaces, in particular the audio mixer, framebuffer and input drivers, but
|
||||||
also the nitpicker GUI server.
|
also the nitpicker GUI server.
|
||||||
|
|
||||||
:qt_avplay: is a Qt4 frontend to 'avplay'. It spawns an instance of 'avplay'
|
:qt_avplay: is a Qt4 front end to 'avplay'. It spawns an instance of 'avplay'
|
||||||
as a slave process.
|
as a slave process.
|
||||||
|
|
||||||
[image media_player]
|
[image media_player]
|
||||||
@ -766,7 +765,7 @@ GUI submits artificial keyboard events with key codes interpreted by the
|
|||||||
|
|
||||||
Besides the separation of the codec from the GUI, the 'qt_avplay' example is
|
Besides the separation of the codec from the GUI, the 'qt_avplay' example is
|
||||||
interesting because it makes use of Genode's new dynamic configuration
|
interesting because it makes use of Genode's new dynamic configuration
|
||||||
facility. The SDL audio backend used by the codec repeatedly evaluates its
|
facility. The SDL audio back end used by the codec repeatedly evaluates its
|
||||||
configuration during runtime. This configuration includes a volume prescale
|
configuration during runtime. This configuration includes a volume prescale
|
||||||
factor. Via the dynamic configuration mechanism, the parent (the GUI) is able
|
factor. Via the dynamic configuration mechanism, the parent (the GUI) is able
|
||||||
to update the value of the volume prescale factor at any time and thereby
|
to update the value of the volume prescale factor at any time and thereby
|
||||||
@ -851,13 +850,13 @@ Noux
|
|||||||
####
|
####
|
||||||
|
|
||||||
Running GCC, binutils, coreutils natively on Genode
|
Running GCC, binutils, coreutils natively on Genode
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
===================================================
|
||||||
|
|
||||||
We introduced support for stacked file systems alongside new glue for accessing
|
We introduced support for stacked file systems alongside new glue code for
|
||||||
file-system implementations provided via Genode's new file-system-session
|
accessing File-system implementations provided via Genode's new
|
||||||
interface. Using stacked file systems, an arbitrary number of file systems
|
file-system-session Interface. Using stacked file systems, an arbitrary number
|
||||||
(such as TAR archives or file systems implemented as separate Genode
|
of file systems (such as TAR archives or file systems implemented as separate
|
||||||
components) can be composed to form one merged virtual file system.
|
Genode Components) can be composed to form one merged virtual file system.
|
||||||
|
|
||||||
An example is given via the 'ports/run/noux_bash.run' script. This run script
|
An example is given via the 'ports/run/noux_bash.run' script. This run script
|
||||||
creates a virtual file system out of multiple TAR archives each containing the
|
creates a virtual file system out of multiple TAR archives each containing the
|
||||||
@ -878,10 +877,10 @@ supported.
|
|||||||
|
|
||||||
|
|
||||||
Networking support
|
Networking support
|
||||||
~~~~~~~~~~~~~~~~~~
|
==================
|
||||||
|
|
||||||
We desire to use a wide range of Unix networking tools such as wget, lynx, ssh,
|
We desire to use a wide range of Unix networking tools such as wget, lynx, ssh,
|
||||||
netcat on Genode. For this reason, the second focus of our Noux-related
|
and netcat on Genode. For this reason, the second focus of our Noux-related
|
||||||
developments is the added support for networking. The Noux syscall interface
|
developments is the added support for networking. The Noux syscall interface
|
||||||
has been extended with system calls for 'socket', 'getsockopt', 'setsockopt',
|
has been extended with system calls for 'socket', 'getsockopt', 'setsockopt',
|
||||||
'accept', 'bind', 'getpeername', 'listen', 'send', 'sendto', 'recv',
|
'accept', 'bind', 'getpeername', 'listen', 'send', 'sendto', 'recv',
|
||||||
|
Loading…
Reference in New Issue
Block a user