Services are encapsulated bits of functionality. They can currently only be provided by userspace tasks, and used from other userspace tasks, through the register_service and subscribe_to_service system calls.
I want to extend this functionality so that the kernel can provide and use services, probably in all four combinations:
Kernel->Kernel is via direct calls, downcasting from dyn KernelService to a concrete type
Kernel->User is by constructing a message of the correct type in kernelspace, and sending it down the Channel to the providing task. A response is then passed back up the channel and needs to be parsed.
User->Kernel is provided by passing the message received from a user task up a channel to a `KernelService
User->User basically already works, and is mediated by channels between user tasks.
This will likely involve building out a more robust service-registration system that can then be used from subscribe_to_service, and in general much more infrastructure for dealing with Ptah messages and Channels from inside the kernel. I'm thinking kernel-provided services can have protocol definitions inside poplar, so the types can be shared between userspace and the kernel.
I also wonder if this is the time to investigate integrating an async runtime into the kernel, and maybe rewriting the syscall interface to be async, to provide an easy way to get the assorted bits of service-running code to run at the correct time. This is a direction I've wanted to take the kernel for a while anyways, so it might be the time to do so. One thing that will need consideration here (that I've not seen anyone else do yet) is to find a way to integrate an async executor with a more traditional userspace scheduler, to fairly distribute CPU time.
Services are encapsulated bits of functionality. They can currently only be provided by userspace tasks, and used from other userspace tasks, through the
register_service
andsubscribe_to_service
system calls.I want to extend this functionality so that the kernel can provide and use services, probably in all four combinations:
dyn KernelService
to a concrete typeChannel
to the providing task. A response is then passed back up the channel and needs to be parsed.This will likely involve building out a more robust service-registration system that can then be used from
subscribe_to_service
, and in general much more infrastructure for dealing with Ptah messages and Channels from inside the kernel. I'm thinking kernel-provided services can have protocol definitions insidepoplar
, so the types can be shared between userspace and the kernel.I also wonder if this is the time to investigate integrating an
async
runtime into the kernel, and maybe rewriting the syscall interface to be async, to provide an easy way to get the assorted bits of service-running code to run at the correct time. This is a direction I've wanted to take the kernel for a while anyways, so it might be the time to do so. One thing that will need consideration here (that I've not seen anyone else do yet) is to find a way to integrate an async executor with a more traditional userspace scheduler, to fairly distribute CPU time.