syscall: add notification mechanism #3252
Conversation
|
I'm sympathetic towards this addition, as it addresses a disparity we introduced in the semantics around buffer sharing in Tock 2.1: capsules can no longer control whether allow operations are granted, and hence have to accept any changes in shared buffers by an application; at the same time they cannot efficiently check whether an allowed buffer was changed. It is noteworthy that in current implementations, userspace can still technically modify the contents of allowed buffers, but this is disallowed for tock/doc/reference/trd104-syscalls.md Lines 586 to 598 in 98d225a Hence I'd argue that this change is in line with the expectations set by TRD 104, although we'd need to clearly communicate that this mechanism is not sufficient to be informed of all permutations of the underlying buffer. I think it's conceivable to use other mechanisms to tell whether a buffer was changed, such as an incrementing counter for allow operations per buffer, in case the proposed method of a method invocation on the driver is deemed to expensive. |
|
I'm convinced we need something like this. However, we've only identified a very specific use case (i.e. reasonably fast streaming data) where this is needed. Yet, adding a new callback to the My question is, can we come up with some API that makes it very clear what the callback is for? Can we make it so that the callback can only modify the grant? Can we pass a reference somehow and have the kernel internally mark something in the grant (and therefore not add the generic callback)? |
|
I will point out this adds 2kB to Imix and 1.5 kB to OT, neither of which have any drivers that use the mechanism |
#3258 does that |
|
Why is there a I am conceptually 100% in favor of this, but the code size increase concerns me. Where is that code coming from, and is there a way to remove it? |
I added this as is became technically possible. Considering @bradjc and @phil-levis concerns about making code review more difficult and adding the ability for capsules to start actions within this notification, I am not against removing it. |
These lines seems to add about 700B to the code. |
|
When we pick this up we should be sure to compare against #3258 |
|
If we add a notification about process state changes (start, stop, restart), this can also re-enable optimizations in drivers such as the Currently drivers have no reliable way of determining whether a process is still alive, and can't perform actions in response to these state changes. These issues also affect other drivers, such as ones that enable a peripheral in response to a userspace request, but won't disable it when the application stops / faults. |
|
Closing in favor of #4023. |
Pull Request Overview
This pull request adds a notification mechanisms that informs syscall drivers about the succesfull
subscribeandallow_readonlyandallow_readwritesystem calls sent by applications.As of Tock 2.1, drivers are not in charge of handling these system calls, but the kernel performs them in the driver's name. This makes drivers unaware of what happens with an application's upcalls and buffers. While most drivers do not need this information, some drivers might want to know when a an application swaps a buffer.
Applications are not allowed to access buffers while they are shared with a driver. In most cases, when an application swaps out a buffer (either unallows it, either provides a replacement for it) it means that the application is consuming the provided data. An example of such behavior is the
touchdriver. The driver receives touch events and places them into a readwrite allowed buffer and notifies the application using an upcall. When the application needs to consume the buffer, it has to swap it out with an empty one. This notification function provides the means to inform the driver that the application has swapped the buffer and that the driver has a new buffer in which it can place a new set of events.Without this type of notification, the application had to issue a supplementary
commandsystem call to inform the driver about the consumption of the buffer.I think this approach will be useful for communication drivers that needs fill in data as fast as possible.
Testing Strategy
This pull request was tested on an STM32F412g Discovery board using the touch driver.
TODO or Help Wanted
Feedback is welcome.
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.