-
Notifications
You must be signed in to change notification settings - Fork 0
Switchboard
The Switchboard class keeps track of what Device Drivers are present, and how to deliver messages to them.
When a device driver starts up, it registers itself with the switchboard as handling messages for a given TASK_NAME.
The message itself is not queued or moved - a pointer to it is passed around. This minimizes the queue size and the processing time involved with copying a message.
Messages are generated with the Messages::future_Message message factory. This pointer is sent using the SwitchBoard::snd(msg *ptr) call. The message immediately becomes owned by the SwitchBoard. The sender must not reference any part of the message just sent. It will be deleted by the SwitchBoard after being delivered.
When a message is sent (with SwitchBoard::snd(msg)), the destination Task Name is looked up. If it is currently registered, its callback invoked with the given message. Note this is currently done in the context of the caller - drivers are required to minimize the time in the callback AS IF it were used in an interrupt context (Implementation note: Drivers MUST NOT call the switchboard from an ISR!). If that
-
Study whether or not to use a 'message queue' on send, and deliver messages using a separate switchboard task.
-
This would isolate the sender and the receiver's task (useful if they are on separate processors) at the cost of delays resulting from the extra context switches. Possibly this behavior could be determined by the driver when it registers itself? Also, should we have separate queues per device, or one single queue? If appropriate defaults were used, the current design allows either approach with no changes to existing drivers.
-
This alternate design leaves open the possibility of delivering over a network or other path not on the current processor, where longer delivery times can be expected.