On 07/05/2004 04:13 PM Philippe Gerum wrote: > 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.
That's not trivial, indeed. >> 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? $ grep LATENCY config.log #define CONFIG_RTAI_SCHED_8254_LATENCY #define CONFIG_RTAI_SCHED_APIC_LATENCY Note that it's OK if RTAI_EXTENDED is used. I think the problem is not x86 specific. Wolfgang.
