RES: Why not a directive rtems_clock_set (rtems_clock_time_value)?

Fabrício de Novaes Kucinskis fabricio at dea.inpe.br
Tue Sep 18 18:57:03 UTC 2007


> History.  Plus more people need to get the time in different formats
> than need to set it in different formats.

> At this point in time, I have grown to dislike the enum overloaded
> style of clock_get.

I'd ask for an enum overloaded style of clock_set, but forget it... :)

Ok, so if I need a clock set function using the rtems_clock_time_value, I
have to create one. Just to ease my work, let me ask: is there an internal
"_Seconds_to_TOD" function or something alike?

Regards,


Fabrício.





-----Mensagem original-----
De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
Enviada em: terça-feira, 18 de setembro de 2007 12:08
Para: Fabrício de Novaes Kucinskis
Cc: RTEMS - Mailing List
Assunto: Re: Why not a directive rtems_clock_set
(rtems_clock_time_value)?


Fabrício de Novaes Kucinskis wrote:
> Hello all,
>
>
> I'm wondering here: if we have ways to get the RTEMS clock counter in the
> "rtems_time_of_day", "rtems_clock_time_value" and "rtems_interval"
formats,
> why there is just one way to set it (with "rtems_time_of_day")?
>
>
History.  Plus more people need to get the time in different formats
than need to set it in different formats.

At this point in time, I have grown to dislike the enum overloaded
style of clock_get.  It makes it harder to have strict typing and
that style of routine tends to reference more support code than
any particular user needs.  Thus it leads to code getting pulled in
that you won't necessarily use.  So I would lean to a new small
routine.  It's all up to users though.
> Why don't we have a way to set the clock in "rtems_clock_time_value"? As
the
> counting is in ticks, I can't see any technical issue here that prevents
> this.
>

There is this from POSIX:

int clock_settime(
  clockid_t              clock_id,
  const struct timespec *tp
)

Some of the code in posix/src is enabled all the time (e.g. sleep and
friends).  Maybe  it makes sense to enable this one also.


> Regards,
>
>
> Fabrício de Novaes Kucinskis - DEA / INPE
> -----------------------------------------------
> Onboard Data Handling Group - SUBORD
> Aerospace Electronics Division
> Brazilian National Institute for Space Research
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>




More information about the users mailing list