On 11/04/2016 23:37, Joel Sherrill wrote:
Ultimately we have to rely on something to do the right thing.
The design issue is a struct and code in the score is dependent on
something in a header in another file in another part of RTEMS, ie
confdefs.h to actually work as expected. It is easy t
On Mon, Apr 11, 2016 at 8:17 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
> - Chris Johns schrieb:
> > On 8/04/2016 7:34 PM, Sebastian Huber wrote:
> > > On 08/04/16 11:22, Chris Johns wrote:
> > >>> I don't think its feasible to avoid . Its now the
> only
> > >>> way to
- Chris Johns schrieb:
> On 8/04/2016 7:34 PM, Sebastian Huber wrote:
> > On 08/04/16 11:22, Chris Johns wrote:
> >>> I don't think its feasible to avoid . Its now the only
> >>> way to create a configuration.
> >>>
> >>
> >> Sorry, but I do not like confdefs getting these values in this way.
On 8/04/2016 7:34 PM, Sebastian Huber wrote:
On 08/04/16 11:22, Chris Johns wrote:
I don't think its feasible to avoid . Its now the only
way to create a configuration.
Sorry, but I do not like confdefs getting these values in this way.
This is not a great long term solution. Easy to add very
On 08/04/16 11:22, Chris Johns wrote:
I don't think its feasible to avoid . Its now the only
way to create a configuration.
Sorry, but I do not like confdefs getting these values in this way.
This is not a great long term solution. Easy to add very hard to remove.
Maybe you need make s
On 8/04/2016 6:30 PM, Sebastian Huber wrote:
The _Assert() is only active in case you use RTEMS_DEBUG.
Then that is no good.
I don't think its feasible to avoid . Its now the only
way to create a configuration.
Sorry, but I do not like confdefs getting these values in this way. This
is
On 08/04/16 10:07, Chris Johns wrote:
On 8/04/2016 5:35 PM, Sebastian Huber wrote:
On 08/04/16 09:06, Chris Johns wrote:
I assume the microsecond, nanosecond and tick per sec values all need
to agree.
Does anything check this is the case and raise a fatal error if they
do not?
Currently no
On 8/04/2016 5:35 PM, Sebastian Huber wrote:
On 08/04/16 09:06, Chris Johns wrote:
I assume the microsecond, nanosecond and tick per sec values all need
to agree.
Does anything check this is the case and raise a fatal error if they
do not?
Currently nobody checks this. Should we check this vi
On 08/04/16 09:06, Chris Johns wrote:
On 8/04/2016 4:49 PM, Sebastian Huber wrote:
This avoids the calculation of this value at run-time, similar to
rtems_configuration_get_nanoseconds_per_tick().
Delete TOD_TICKS_PER_SECOND and replace it with
rtems_configuration_get_ticks_per_second().
---
On 8/04/2016 4:49 PM, Sebastian Huber wrote:
This avoids the calculation of this value at run-time, similar to
rtems_configuration_get_nanoseconds_per_tick().
Delete TOD_TICKS_PER_SECOND and replace it with
rtems_configuration_get_ticks_per_second().
--- a/cpukit/sapi/include/confdefs.h
+++ b/cp
This avoids the calculation of this value at run-time, similar to
rtems_configuration_get_nanoseconds_per_tick().
Delete TOD_TICKS_PER_SECOND and replace it with
rtems_configuration_get_ticks_per_second().
---
cpukit/posix/src/alarm.c | 3 ++-
cpukit/sapi/include/confdefs.h
11 matches
Mail list logo
