Commit Graph

16 Commits

Author SHA1 Message Date
Norman Feske
f186587cab Unify ipc_msgbuf.h across base platforms
Besides unifying the Msgbuf_base classes across all platforms, this
patch merges the Ipc_marshaller functionality into Msgbuf_base, which
leads to several further simplifications. For example, this patch
eventually moves the Native_connection_state and removes all state
from the former Ipc_server to the actual server loop, which not only
makes the flow of control and information much more obvious, but is
also more flexible. I.e., on NOVA, we don't even have the notion of
reply-and-wait. Now, we are no longer forced to pretend otherwise.

Issue #1832
2016-04-25 10:47:59 +02:00
Norman Feske
cda07b7da0 base: simplification of the IPC code
This commit replaces the stateful 'Ipc_client' type with the plain
function 'ipc_call' that takes all the needed state as arguments.
The stateful 'Ipc_server' class is retained but it moved from the public
API to the internal ipc_server.h header. The kernel-specific
implementations were cleaned up and simplified. E.g., the 'wait'
function does no longer exist. The badge and exception code are no
longer carried in the message buffers but are handled in kernel-specific
ways.

Issue #610
Issue #1832
2016-04-11 11:51:42 +02:00
Norman Feske
47878bd3e1 Remove 'Ipc_istream' and 'Ipc_ostream' from API
Fixes #610
2016-04-11 11:51:42 +02:00
Norman Feske
4cdfb9bc2f base: remove 'Native_connection_state' from API
Issue #1832
2016-04-11 11:51:42 +02:00
Norman Feske
da5d182ad3 base: remove 'Native_thread' from public API
Issue #1832
2016-04-11 11:51:42 +02:00
Norman Feske
84bfb4c04c base: remove 'Native_thread_id' type
Issue #1832
2016-03-18 22:43:01 +01:00
Norman Feske
9b0eb720b0 base: remove 'Native_utcb' from public API
Fixes #1905
2016-03-17 17:02:04 +01:00
Norman Feske
9a3185f8ed base-linux: remove chroot support
Fixes #1903
2016-03-08 17:00:54 +01:00
Norman Feske
76db3b9c06 base: retire 'Native_config'
This commit moves the parameters of the stack area to the base-internal
header 'stack_area.h'.

Issue #1832
2016-03-08 17:00:54 +01:00
Norman Feske
7f73e5e879 base: hide internals of the Thread API
This patch moves details about the stack allocation and organization
the base-internal headers. Thereby, I replaced the notion of "thread
contexts" by "stacks" as this term is much more intuitive. The fact that
we place thread-specific information at the bottom of the stack is not
worth introducing new terminology.

Issue #1832
2016-03-07 12:34:46 +01:00
Norman Feske
8132a16137 base-linux: make linux-specific headers private
The interfaces linux_cpu_session, local_capability, linux_dataspace,
linux_native_pd are mere implementation necessities. They are meant for the
internal use by the framework only. So it is appropriate to move them to
base/internal/.

Issue #1832
2016-03-07 12:34:46 +01:00
Norman Feske
2e701f9afa base: update include guards
This patch cleans up the include guards, assisted by the
tool/fix_include_ifndef script.
2016-03-07 12:34:45 +01:00
Sebastian Sumpf
41b9f6bd03 ldso: Make truly self relocatable
On Linux the linker can now be loaded at arbitrary addresses, this became
necessary for newer kernel versions. The 'linux_arm' target is not supported.

Issue #1728
2015-12-10 13:16:25 +01:00
Stefan Kalkowski
2a351215f4 base: remove pager code from public API
Fix #1593
2015-07-01 14:46:15 +02:00
Stefan Kalkowski
b949489641 base: remove local capability from generic base
* Instead of using local capabilities within core's context area implementation
  for stack allocation/attachment, simply do both operations while stack gets
  attached, thereby getting rid of the local capabilities in generic code
* In base-hw the UTCB of core's main thread gets mapped directly instead of
  constructing a dataspace component out of it and hand over its local
  capability
* Remove local capability implementation from all platforms except Linux

Ref #1443
2015-04-17 16:13:20 +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