Re: [Xenomai-core] autostart timer, rt_timer_start/stop

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Stefan Kisdaroczi wrote:
>>
>>> Hi,
>>>
>>> cant the timer be started by default ?
>>>
>>> The current state (2.0.1) seems to lead to the following scenario:
>>> 1) Every app calls rt_timer_start()
>>> 2) If you call rt_timer_stop you can hurt other rt-apps, so dont
>>>   call it
>>> 3) As some apps dont stop the timer, check in 1) if its already running
>>>
>>> I think most apps do not care in which mode the timer is running if
>>> it is already,
>>> and just go on, of course you can stop and restart the timer if its a
>>> wrong state,
>>> but you do not know if you hurt others.
>>>
>>> Now, as i read in the other thread that the periodic timer support
>>> isnt configured by default,
>>> why not start the oneshot timer automatic ?
>>>
>>> Like this, a 'normal' app doesnt need to fiddle with the timer and
>>> an app that really cares can still call rt_timer_inquire,_stop,_start.
>>>
>>
>>
>> Yea, that's good that someone else brings this topic up again! :) I've
>> been pointing on this several times, but as we did not come to a
>> conclusion how to handle the system timer in a consistent way across all
>> skins, no one (me included...) came up with a fix of this issue so far.
>>
> 
> Looks like pending, indeed:
> https://gna.org/bugs/?func=detailitem&item_id=4551
> 

Ha, totally forgot this one - I actually posted it. :)

>> The thing is that most skins start the timer during module init via some
>> parameter (nowadays also as a kernel boot option for compiled-in skins).
>> As far as I remember, only the native and the RTAI compat skin do their
>> own dance - the latter one has to remain compatible, ok, but the former
>> one should be allowed to perform smarter.
>>
>> Ok, to be more concrete: autostarting the one-shot time in the absence
>> of periodic mode is certainly worth considering. For the other cases and
>> as sysfs is no option on 2.4 kernels, what about adding a /proc-exported
>> control mechanism for the timer mode (and period) to either the HAL or
>> the nucleus?
> 
> 
> Nucleus.
> 
>  Additionally, we could provide some CONFIG_xyz to set the
> 
>> default mode during compile time.
>>
> 
> Since we can't have more than a single timer setting at any time, a
> CONFIG switch in the General menu would be ok. In such a case, moving
> the currently arch-dep CONFIG_XENO_HW_PERIODIC_TIMER to the General
> config section would make sense too, so that we would have all timer
> options at the same place (periodic timing can always be emulated using
> some underlying oneshot hw timer, and all archs are expected to provide
> at least some form of oneshot timer anyway).
> 
>> Ceterum censeo rt_timer_start/stop esse delendam. ;)
>>
> 
> Perhaps not, otherwise we would have some trouble crafting tests and
> benchmarks for instance. But these are indeed relics from the Stone Age
> we'd better deprecate for normal use.
> 

Let's assume we have extended /proc/xenomai/timer by accepting the timer
period as input (comparable to tick_hz module paramters of some skins),
we could simply tune it at benchmark startup by issuing "echo 0 >
/proc/xenomai/timer", either in the start script or from within the
application.

BTW, would the /proc/xenomai/timer interface make sense to you?

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]