Reframing IPC as XDC

Site Feedback
1

The pop-culture opinion of microkernels is that IPC is their achilles heel, even though the style of IPC seL4 uses is much faster than Unix or Mach. I would like to suggest reframing all seL4/LionsOs IPC to Cross Domain Communication (XDC ) which breaks down into three layers:

  • Control Rail = Protected Procedure Call
  • Data Channel = shared-memory / ring-buffers (use buzzwords!)
  • Notifications = signaling / events

I’m not super in love with “Control Rail”, but the LLM makes a plausible sounding analogy (not sure how accurate it is):

We don’t ‘send a message’ to a driver. We perform Protected Procedure Calls across the Control Rail . The capability is the physical connection; the kernel is just the high-speed switch that completes the circuit.

I brought this up in the developer chat and it was well received. However, I didn’t discuss this specific terminology and that will need to get hammered out here first. Some alternatives I played around with:

  • Control|Coordination Plane|Path
  • Data Plane|Path
  • Signaling Plane|Path

Please give feedback and make suggestions if you have any!

Next Steps

It’s not feasible nor productive to update all code and documentation to use this terminology. But once y’all decide on terminology, the next step would be to use it for all new documentation, code, and public messaging. Existing documentation will get refactored/rewritten slowly. Maybe someday create aliases for existing code using the “IPC” label – but again that’s very low priority.

Talking Points

Prefab responses for when someone makes the “IPC is slow” objection:

seL4/LionsOS doesn’t do Unix or Mach style IPC, we do XDC : Cross Domain Communication .

We weren’t dumb enough to implement ‘everything is a heavyweight message’ IPC in seL4. seL4 uses XDC (Cross Domain Communication), which separates control transfer, bulk data movement, and event signaling into three different layers.

  • Small control exchanges should use protected procedure calls .
  • Bulk transfer should use ring-buffer|shared-memory data channels .
  • Async readiness is signaled via notifications .
2

On second thought, fuck the LLM: Control Rail requires explanation. I think this breakdown makes more sense:

  • XDC Umbrella Term
  • Control Channel Protected Procedure Call
  • Data Channel shared memory/ring buffers.
  • Signaling Channel notifications/async

These categories give directional guidance to what each is used for. Please let me know if you have feedback.