genode

History

Josef Söntgen 9b7e0ce0a5 part_blk: add GPT support The GUID partition table (GPT) is primarily used by systems using (U)EFI and is a replacement for the legacy MBR. For now, the current implementation is able to address up to 128 GUID partition entries (GPE). To enable the GPT support in 'part_blk' it has to be configured accrodingly: ! <start name="part_blk"> ! [...] ! <config use_gpt="yes"> ! [...] ! </start> If 'part_blk' is not able to find a valid GPT header it falls back to using the MBR. Current limitations: Since no endian conversion takes place it only works on LE platforms and of all characters in the UTF-16 encoded name field of an entry only the ones included in the ASCII encoding are printed. It also ignores all GPE attributes. Issue #1429.		2015-03-19 09:22:37 +01:00
..
README	part_blk: add GPT support	2015-03-19 09:22:37 +01:00
component.h	part_blk: add GPT support	2015-03-19 09:22:37 +01:00
driver.h	Move repositories to 'repos/' subdirectory	2014-05-14 16:08:00 +02:00
gpt.h	part_blk: add GPT support	2015-03-19 09:22:37 +01:00
main.cc	part_blk: add GPT support	2015-03-19 09:22:37 +01:00
mbr.h	part_blk: add GPT support	2015-03-19 09:22:37 +01:00
partition_table.h	part_blk: add GPT support	2015-03-19 09:22:37 +01:00
target.mk	Move repositories to 'repos/' subdirectory	2014-05-14 16:08:00 +02:00

README

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="test-part1" partition="6"/>
!    <policy label="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>