change log for rtems (2011-09-29)

[Sebastian Huber]

On 09/29/2011 04:13 PM, Ralf Corsepius wrote:
> On 09/29/2011 12:10 PM, rtems-vc at rtems.org wrote:
>> *sh*
>
>
>
>> diff -u rtems/cpukit/score/src/ts64set.c:1.2
>> rtems/cpukit/score/src/ts64set.c:1.3
>> --- rtems/cpukit/score/src/ts64set.c:1.2 Wed Sep 28 09:42:12 2011
>> +++ rtems/cpukit/score/src/ts64set.c Thu Sep 29 04:55:54 2011
>> @@ -22,8 +22,8 @@
>> #if CPU_TIMESTAMP_USE_INT64 == TRUE
>> void _Timestamp64_Set(
>> Timestamp64_Control *_time,
>> - long _seconds,
>> - long _nanoseconds
>> + Timestamp64_Control _seconds,
>> + Timestamp64_Control _nanoseconds
>
> I don't like this change and other timespec removals inside of this patch).

The timestamp API should be independent of the timespec.  You can use timespec 
fields and pass them as parameters.  On the other hand you can also use the 
uint32_t from _TOD_To_seconds().

>
> Can't we simply agree upon using timespec and its convention of
> "time_t = secs" and "long = nanosecs", instead?

In general yes, but not in this case.  If we use long here, we may loose 
information (e.g. in combination with _TOD_To_seconds()).

We should consider to change

rtems_status_code rtems_clock_get_seconds_since_epoch(
   rtems_interval *the_interval
);

and similar to

rtems_status_code rtems_clock_get_seconds_since_epoch(
   time_t *the_interval
);

This would eliminate the need for such exceptions, e.g.

   void _Timestamp64_Set(
     Timestamp64_Control *_time,
     time_t               _seconds,
     long                 _nanoseconds
   );

would be ok then.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.