On Mon, 2004-07-05 at 15:55, Wolfgang Grandegger wrote:
> On 07/05/2004 03:36 PM Philippe Gerum wrote:
> > On Mon, 2004-07-05 at 15:01, Wolfgang Grandegger wrote:
> >> On 07/05/2004 01:10 PM Philippe Gerum wrote:
> >> > On Mon, 2004-07-05 at 12:22, Wolfgang Grandegger wrote:
> >> >> Hi Philippe,
> >> >> 
> >> >> as announced, RTHAL is no longer supported in RTAI 3.1 on x86 but I
> >> >> prefer to keep the legacy RTAI for PowerPC for one or two more releases.
> >> >> Do you see a problem with configuration, names, etc.?
> >> > 
> >> > No problem. 3.0 paved the way to this kind of combination for x86 which
> >> > can/should be kept until the Adeos-based implementation is stable.
> >> 
> >> Well, there are a few problems with vesuvio:
> >> 
> >>  - rtai-core/malloc/malloc.c includes rtai_hal.h directly (easy to fix).
> > 
> > Yep, <rtai.h> would be better.
> 
> You will fix it? In any case I will do it when I checkin the RTAI over
> ADEOS PowerPC port.
> 
> > 
> >>  - the RTAI scheduler files, apart from sched_up.h, now use the new
> >>    RTAI_* macros, e.g. RTAI_LATENCY_8254, which are not available in
> >>    legacy RTAI.
> >> 
> > 
> > Namespace depollution. In any case, this is only an additional RTAI_
> > prefix, the meaning of the modified macros does not change. There is a
> > rtai_oldnames.h files in x86 that provides for compatibility with the
> > older naming scheme.
> 
> Well, I know. But "rtai_oldnames.h" is not used by legacy RTAI.
> Nevertheless, on non-x86 archs only sched_up.c is used, which still uses
> the old names.
> 

I guess that adding the RTAI_ prefixed version of macros for archs
needing MUP/SMP/LXRT schedulers would be the best way then. Anyway, the
real problem is that the 8254/APIC stuff should not appear in the
non-x86 ports, but this is probably not the simplest fix here. 

> I have a more boring problem with CONFIG_RTAI_SCHED_8254_LATENCY. If
> RTAI_EXTENDED is not set it will be defined in rtai_config.h as shown:
> 
>   #define CONFIG_RTAI_SCHED_8254_LATENCY
> 
> This makes it difficult to set a proper default. "#undef" would be
> better. Any ideas?
> 

This symbol is not a toggle but rather bears a value. It is strange to
have it empty since configure.in should prevent this and leave a default
value (4700) instead. What is the output of "8254 tuning latency" in the
configure output log?

> Wolfgang.
> 
> _______________________________________________
> Rtai-dev mailing list
> [EMAIL PROTECTED]
> https://mail.gna.org/listinfo/rtai-dev
-- 

Philippe.


Reply via email to