Date: Thu, 09 Sep 2010 12:56:29 +0300 From: Alexander Motin <mav@FreeBSD.org> To: "Cherry G. Mathew" <cherry@zyx.in> Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure Message-ID: <4C88AF4D.4020903@FreeBSD.org> In-Reply-To: <4C88AC08.7070502@zyx.in> References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> <4C872AA4.5020906@zyx.in> <4C8738DA.80604@FreeBSD.org> <4C88AC08.7070502@zyx.in>
next in thread | previous in thread | raw e-mail | index | archive | help
Cherry G. Mathew wrote: > To summarise, > > My two concerns were: > I) > a) If there is a non-optional device specific callback (like a timer > isr) tied to specific timer on a vendor board > b) a "generic" non-device specific callback that uses the ET framework > and acquires the timer in "a)" before the isr/callback in "a)" could > obtain it. > > how can the API ensure that this scenario: > > i) doesn't happen > or > ii) can be subsequently rectified Using event timer (unlike time counter) most likely means programming it. Without enough complicated midlayer two consumers won't be able to use single timer, unless it ticks at fixed frequency and doesn't allow any programming. For this reason I wasn't expecting any sharing. We could extend API to allow shared event timer usage, but in that case only one consumer should control it, while all other's just receive these events and trust that timer programmed as they expect. At this moment I don't see practical reason where such functionality would be needed. Do you have some? > AND > II) > Did the api need to be fleshed out separately of timertc.h ? API is in stage of development and was changes few times since originally created. May be some ideas, like yours, could affect it again. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C88AF4D.4020903>