mirror of
https://github.com/genodelabs/genode.git
synced 2025-06-01 07:00:55 +00:00
1336b0a751
The classes Genode::Mmio, Genode::Register_set, Genode::Attached_mmio, and Platform::Device::Mmio now receive a template parameter 'size_t SIZE'. In each type that derives from one of these classes, it is now statically checked that the range of each Genode::Register::Register- and Genode::Register_set::Register_array-deriving sub-type is within [0..SIZE). That said, SIZE is the minimum size of the memory region provided to the above mentioned Mmio classes in order to avoid page faults or memory corruption when accessing the registers and register arrays declared inside. Note, that the range end of a register array is not the end of the last item but the end of integer access that is used for accessing the last bit in the last item. The constructors of Genode::Mmio, Genode::Attached_mmio, and Platform::Device::Mmio now receive an argument 'Byte_range_ptr range' that is expected to be the range of the backing memory region. In each type that derives from on of these classes, it is now dynamically checked that 'range.num_bytes >= SIZE', thereby implementing the above mention protection against page faults and memory corruption. The rest of the commit adapts the code throughout the Genode Labs repositories regarding the changes. Note that for that code inside Core, the commits mostly uses a simplified approach by constructing MMIO objects with range [base..base+SIZE) and not with a mapping- or specification-related range size. This should be fixed in the future. Furthermore, there are types that derive from an MMIO class but don't declare any registers or register arrays (especially with Platform::Device::Mmio). In this case SIZE is set to 0. This way, the parameters must be actively corrected by someone who later wants to add registers or register arrays, plus the places can be easily found by grep'ing for Mmio<0>. Fix #4081
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). It will
always try to read the MBR as well as the GPT and will bail out if both are
considered valid. It is up to the user to choose the right table. To do so,
the 'ignore_mbr' or 'ignore_gpt' config attribute may be specified. Using both
at the same time is a configuration error. Apart from that, the server will
show a warning in case a protective MBR is found but GPT is ignored and abort.
If valid GPT was encountered without a proper protective MBR it will use the
GPT but show a diagnostic warning.
In order to route a client to the right partition, the server parses its
configuration section looking for 'policy' tags.
XML Syntax:
! <policy label="<program name>" partition="<partition number>" writeable="<boolean>"/>
part_block supports partition reporting, which can be enabled via the
<report> configuration node. See below for an example. The report
looks like follows (for MBR resp. GPT).
! <partitions type="mbr">
! <partition number="1" type="12" start="2048" length="2048"/>
! <partition number="2" type="15" start="4096" length="16384"/>
! <partition number="5" type="12" start="6144" length="4096"/>
! <partition number="6" type="12" start="12288" length="8192"/>
! </partitions>
! <partitions type="gpt">
! <partition number="1" name="one" type="ebd0a0a2-b9e5-4433-87c0-68b6b72699c7"
! guid="5f4061cc-8d4a-4e6f-ad15-10b881b79aee" start="2048" length="2048"/>
! <partition number="2" name="two" type="ebd0a0a2-b9e5-4433-87c0-68b6b72699c7"
! guid="87199a83-d0f4-4a01-b9e3-6516a8579d61" start="4096" length="16351"/>
! </partitions>
Clients have read-only access to partitions unless overriden by a 'writeable'
policy attribute.
part_block requests a block session to access the storage device with a
4 MiB I/O buffer per default. The buffer size can be tweaked with the
'io_buffer' config attribute.
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_block">
! <resource name="RAM" quantum="10M" />
! <provides><service name="Block" /></provides>
!
! <!-- route part_block 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, the buffer between
! the 'ata_driver' and 'part_block' is 1 MiB ('io_buffer') -->
! <config io_buffer="1M">
! <report partitions="yes"/>
! <policy label_prefix="test-part1" partition="6" writeable="yes"/>
! <policy label_prefix="test-part2" partition="1" writeable="yes"/>
! </config>
!</start>
!
!<!-- part_block clients -->
!<start name="test-part1">
! <binary name="test-part"/>
! <resource name="RAM" quantum="10M" />
! <route>
! <any-service> <child name="part_block" /> <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_block" /> <parent/> <any-child/> </any-service>
! </route>
!</start>