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  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.
The EROS Group, LLC
More information about the l4-hackers