mirror of
https://github.com/genodelabs/genode.git
synced 2025-01-19 19:26:29 +00:00
5a1cef6381
This patch unconditionally applies the labeling of sessions and thereby removes the most common use case of 'Child_policy::filter_session_args'. Furthermore, the patch removes an ambiguity of the session labels of sessions created by the parent of behalf of its child, e.g., the PD session created as part of 'Child' now has the label "<child-name>" whereas an unlabeled PD-session request originating from the child has the label "<child-name> -> ". This way, the routing-policy of 'Child_policy::resolve_session_request' can differentiate both cases. As a consequence, the stricter labeling must now be considered wherever a precise label was specified as a key for a session route or a server- side policy selection. The simplest way to adapt those cases is to use a 'label_prefix' instead of the 'label' attribute. Alternatively, the 'label' attribute may used by appending " -> " (note the whitespace). Fixes #2171
70 lines
2.4 KiB
Plaintext
70 lines
2.4 KiB
Plaintext
This directory contains an implementation of a block-device-partition server.
|
|
|
|
Behavior
|
|
--------
|
|
|
|
The server uses Genode's block-session interfaces as both front and back end,
|
|
leading to the most common use case where this server will reside "between" a
|
|
block-driver server and a higher level component like a file-system server.
|
|
|
|
At startup, the partition server will try to parse the master boot record (MBR)
|
|
of its back-end block session. If no partition table is found, the whole block
|
|
device is exported as partition '0'. In the other case, the MBR and possible
|
|
extended boot records (EBRs) are parsed and offered as separate block sessions
|
|
to the front-end clients. The four primary partitions will receive partition
|
|
numbers '1' to '4' whereas the first logical partition will be assigned to '5'.
|
|
|
|
The partition server also understands the GUID partition table (GPT). If the
|
|
config attribute 'use_gpt' is set to 'yes' it will first try to parse any
|
|
existing GPT. In case there is no GPT it will fall back to parsing the MBR.
|
|
|
|
In order to route a client to the right partition, the server parses its
|
|
configuration section looking for 'policy' tags.
|
|
|
|
XML Syntax:
|
|
! <policy labal="<program name>" parition="<partition number>" />
|
|
|
|
Usage
|
|
-----
|
|
|
|
Configuration snippet with two clients and an (hypothetical) IDE driver:
|
|
!<start name="ata_driver">
|
|
! <resource name="RAM" quantum="1M" />
|
|
! <provides><service name="Block"/></provides>
|
|
! <config ata="yes" />
|
|
!</start>
|
|
!
|
|
!<start name="part_blk">
|
|
! <resource name="RAM" quantum="10M" />
|
|
! <provides><service name="Block" /></provides>
|
|
!
|
|
! <!-- route part_blk to the ata_driver -->
|
|
! <route>
|
|
! <any-service><child name="ata_driver"/> <parent/><any-child/></any-service>
|
|
! </route>
|
|
!
|
|
! <!-- allow program 'test-part1' to access logical partition '6', while program
|
|
! 'test-part2' receives access to primary partition 1 -->
|
|
! <config>
|
|
! <policy label_prefix="test-part1" partition="6"/>
|
|
! <policy label_prefix="test-part2" partition="1"/>
|
|
! </config>
|
|
!</start>
|
|
!
|
|
!<!-- part_blk clients -->
|
|
!<start name="test-part1">
|
|
! <binary name="test-part"/>
|
|
! <resource name="RAM" quantum="10M" />
|
|
! <route>
|
|
! <any-service> <child name="part_blk" /> <parent/> <any-child/> </any-service>
|
|
! </route>
|
|
!</start>
|
|
!
|
|
!<start name="test-part2">
|
|
! <binary name="test-part"/>
|
|
! <resource name="RAM" quantum="10M" />
|
|
! <route>
|
|
! <any-service> <child name="part_blk" /> <parent/> <any-child/> </any-service>
|
|
! </route>
|
|
!</start>
|