The below commits enable a pd to be "passive" by signalling the monitor to then remove a pd's scheduling context and bind it with that pd's notification objects.
Users can specify a pd is passive by setting adding a boolean to the system xml. In order for the passive server to run, it needs a notification object and cap.
In order to properly initialise, the passive server requires a scheduling context to start with. Once initiliased, the passive server then signals to the monitor that initialisation is complete, and the monitor will then unbind the passive server's scheduling context, and instead bind it to the passive server's notification cap. This is required so that the passive server will be scheduled when it gets a notification.
The below commits enable a pd to be "passive" by signalling the monitor to then remove a pd's scheduling context and bind it with that pd's notification objects. Users can specify a pd is passive by setting adding a boolean to the system xml. In order for the passive server to run, it needs a notification object and cap. In order to properly initialise, the passive server requires a scheduling context to start with. Once initiliased, the passive server then signals to the monitor that initialisation is complete, and the monitor will then unbind the passive server's scheduling context, and instead bind it to the passive server's notification cap. This is required so that the passive server will be scheduled when it gets a notification.