Changes

Jump to navigation Jump to search
904 bytes added ,  23:56, 27 March 2016
no edit summary
Line 169: Line 169:  
|}
 
|}
   −
== Usage Examples for other Translation Types ==
+
== Buffer Mapping Translation ==
 +
 
 +
The IPC subsystem can temporarily map a whole buffer of the sender's memory into the receiver's memory space. This is useful for large buffers, for which the overhead of copying static buffer data around would be too expensive.
 +
 
 +
This kind of translation is enabled by setting bit3 in the translation descriptor. The other two bits of what's documented as the translation type above are used to specify buffer access permissions of the receiving process.
 +
 
 +
Buffers will get mapped at virtual address 0x04000000+ in the destination process.
    
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Type
+
Bits
! scope="col" width="300" |  Usual form
   
!  Description
 
!  Description
 
|-
 
|-
| 2
+
| 1-2
| 0x00000004 <nowiki>|</nowiki> (size<<8) <nowiki>|</nowiki> (id<<4)
+
| Access permission flags for the receiving process: 1=read-only, 2=write-only, 3=read-write. Specifying 0 will cause a kernel panic.
<ptr>
  −
| This is used for RW buffers over PXI. The address written to the destination cmd-buf is a phys-addr for a table located in the BASE memregion. This table contains the phys-addrs for the actual data, the array entries have the following format: {u32 *datachunk_physaddr, u32 datachunk_bytesize}.
   
|-
 
|-
 
| 3
 
| 3
| 0x00000006 <nowiki>|</nowiki> (size<<8) <nowiki>|</nowiki> (id<<4)
+
| Characteristically 1 for this translation type.
<ptr>
+
|-
| Same as above except for read-only buffer.
+
| 4-??
 +
| Size in bytes of the shared memory block.
 +
|}
 +
 
 +
Usage examples:
 +
{| class="wikitable" border="1"
 +
|-
 +
! scope="col" width="300" |  Usual form
 +
!  Description
 
|-
 
|-
| 4
   
| 0x00000008
 
| 0x00000008
| This command will cause a kernelpanic.
+
| This command will cause a kernel panic.
 
|-
 
|-
| 5
   
| <nowiki>0x0000000A | (size<<4)</nowiki>
 
| <nowiki>0x0000000A | (size<<4)</nowiki>
 
<ptr>
 
<ptr>
| The corresponding value contains a ptr to a buffer of said size. It is mapped R- in the destination process??
+
| The corresponding value contains a ptr to a buffer of said size. It is mapped read-only in the destination process.
 
|-
 
|-
| 6
   
| 0x0000000C <nowiki>|</nowiki> (size<<4)
 
| 0x0000000C <nowiki>|</nowiki> (size<<4)
 
<ptr>
 
<ptr>
| The corresponding value contains a ptr to a buffer of said size. It is mapped -W in the destination process??
+
| The corresponding value contains a ptr to a buffer of said size. It is mapped write-only in the destination process.
 
|-
 
|-
| 7
   
| 0x0000000E <nowiki>|</nowiki> (size<<4)
 
| 0x0000000E <nowiki>|</nowiki> (size<<4)
 
<ptr>
 
<ptr>
| The corresponding value contains a ptr to a buffer of said size. It is mapped RW in the destination process??
+
| The corresponding value contains a ptr to a buffer of said size. It is mapped read-write in the destination process.
 
|}
 
|}
   −
Buffers from commands 5,6,7 will get mapped at virtual address 0x04000000+ in destination process.
+
== Usage Examples for other Translation Types ==
 +
 
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Type
 +
! scope="col" width="300" |  Usual form
 +
!  Description
 +
|-
 +
| 2
 +
| 0x00000004 <nowiki>|</nowiki> (size<<8) <nowiki>|</nowiki> (id<<4)
 +
<ptr>
 +
| This is used for RW buffers over PXI. The address written to the destination cmd-buf is a phys-addr for a table located in the BASE memregion. This table contains the phys-addrs for the actual data, the array entries have the following format: {u32 *datachunk_physaddr, u32 datachunk_bytesize}.
 +
|-
 +
| 3
 +
| 0x00000006 <nowiki>|</nowiki> (size<<8) <nowiki>|</nowiki> (id<<4)
 +
<ptr>
 +
| Same as above except for read-only buffer.
 +
|}
549

edits

Navigation menu