genode/repos/base
Emery Hemingway 57fd4e9148 Add Io_progress_handler to Entrypoint interface
The "schedule_post_signal_hook" method of the Genode::Entrypoint class
is problematic because the signal hook can be scheduled and replaced
multiple times during the signal dispatch cycle. Add an alternative to
this method with "register_io_progress_handler" and the "Post_signal_
hook" class with "Io_progress_handler". The difference being an
"Io_progress_handler" may be registered once during the lifetime of an
entrypoint to prevent arbitrary libraries from replacing a pending hook.

The "register_io_progress_handler" remains as a deprecated API, and is
now invoked for every I/O signal received and only for I/O signals
rather than for any signal.

Ref #3132
2019-03-18 15:56:22 +01:00
..
etc Let default tools.conf cover each architecture 2016-07-15 11:38:26 +02:00
include Add Io_progress_handler to Entrypoint interface 2019-03-18 15:56:22 +01:00
lib base: synchronize signal-proxy thread destruction 2019-02-19 11:12:12 +01:00
mk zynq: restructure nic_drv spec structure 2019-02-26 14:47:02 +01:00
ports grub2: avoid switching modes 2018-06-12 12:11:44 +02:00
recipes depot: update recipe hashes 2019-02-28 11:34:45 +01:00
run zynq: restructure nic_drv spec structure 2019-02-26 14:47:02 +01:00
src Add Io_progress_handler to Entrypoint interface 2019-03-18 15:56:22 +01:00
xsd base_types.xsd: allow session labels of length 0 2018-11-16 14:37:19 +01:00
README core: add information about infos provided by core 2017-06-29 11:59:52 +02:00

This is generic part of the Genode implementation. It consists of two parts:

:_Core_: is the ultimate root of the Genode application tree
  and provides abstractions for the lowest-level hardware resources
  such as RAM, ROM, CPU, and generic device access. All generic parts of Core
  can be found here - for system-specific implementations refer to the
  appropriate 'base-<system>' directory.

:_Base libraries and protocols_: that are used by each Genode component
  to interact with other components. This is the glue that holds everything
  together.

_Core_ may export information about the hardware platform by an ROM
called 'platform_info'. Depending on the platform, e.g. ARM or x86 or riscv,
and depending on the boot mode and boot loader and kernel, some nodes may not
be populated.

!<platform_info>
! <acpi revision="2" rsdt="0x1fe93074" xsdt="0x1fe930e8"/>
! <boot>
!   <framebuffer phys="0x7300000" width="1024" height="768" bpp="32"/>
! </boot>
!</platform_info>

If the ACPI RSDT and XSDT physical pointer is reported by the used kernel
and/or bootloader, _Core_ may provide this information by the ROM.

If the graphic device is initialised and can be directly used by a framebuffer
driver, _Core_ may provide the physical pointer to the framebuffer, the
resolution and color depth in bits.