Hi Menno, Sebastian,
On 02/18/2016 01:17 PM, Menno Valkema wrote:
- Will this support all the features a timer needs? Did we take the
right approach here?
I think yes. AFAIK, there must be a way to install a timeout that provides asynchronous feedback (it's not necessary to use IRQs for that) and it must be possible to sample the timer value plus the according overrun status. The overrun status is the information whether the last installed timeout was expired at the time of the sample. The overrun status is reset when a new timeout gets installed.
- Can we be sure the memory we now allocated for our software time
controller, won't be allocated for other uses later?
Yes. If you provide your IO memory through the IOMEM service and try to open a second session to it, the server complains like ...
I/O memory [x,y) not available Local MMIO mapping failed!
... and sends a Genode::Parent::Service_denied exception to the client.
- We've made some riscv-specific changes in non risc-v source code. Is
the scheduler the best place to make these changes? Is there a possibility to move these changes to a riscv specific directory and call these with a callback, so that the code still works for other platforms.
As Sebastian said, we're playing with the idea to move to a kernel-driven timer in general or at least in base-hw. But it is not clear now whether this idea actually brings the benefits we're hoping for and by now, there's also no one working at it. Thus, I would suggest to move the RISCV-specific implementation into separate files for now. You can do this by declaring the hooks in the generic header [1] and implementing them in a new RISCV-specific unit [2]. You would then have to add the unit to 'SRC_CC' in [3].
Cheers, Martin
[1] base-hw/src/core/include/kernel/cpu_scheduler.h [2] base-hw/src/core/spec/riscv/kernel/cpu_scheduler.cc [3] base-hw/lib/mk/spec/riscv/core.mk