software time controller

Menno Valkema menno.genode at ...9...
Thu Feb 25 15:19:40 CET 2016


Hi Martin, Sebastian,

Thank you for thinking along. Your replies give us confidence in our
current implementation, so that we can move forward with it.

A general kernel timer interface would probably help for this specific
cpu architecture in the future, however as this does not exist presently
we will stick to our current approach for now.

Thanks, Menno


On 19-02-16 17:45, Martin Stein wrote:
> 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
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 




More information about the users mailing list