Typed items and the 'C' bit

Jonathan S. Shapiro shap at eros-os.com
Sat Apr 28 18:08:02 CEST 2007

The L4.x2 specification states:

  1. The 'C' bits of typed items and the 't' field of IPW0 redundantly
     encode the number of typed items. This is intentional.

  2. The sender ignores the 'C' bits, but sets them for the receiver.

     [This is required because the sender may set the C bits
      incorrectly, and the path in the kernel that interprets them
      must have a small, bounded number of iterations. If the kernel
      believes the 'C' bits of the type field, a very large number
      of iterations could be created and the receiver-side "frame" for
      words could be overwritten by the sender.]

  3. The specifcation *alleges* that the C bit provides a performance
     advantage to the receiver in parsing the arguments.

I am not convinced that [3] is true. The typed items have variable
length, which means that the receiver must parse the type fields in
order to iterate over them. The only complex case is string items having
a non-zero 'c' (continue) bit, and the specification is explicit that
for these cases the "type" field of the successor stringitem is entirely

Question: does the 'C' bit provide a real advantage, or is it a
historical curiosity?  If there is an advantage, can somebody give an
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC

More information about the l4-hackers mailing list