[Xenomai-core] v2.1 status

[Xenomai-core] v2.1 status

[Philippe Gerum]

Here is an update regarding the way things progress on the v2.1 branch:

o The build system has been deeply revamped, so that we now fully leave the burden of 
building Xenomai's kernel support to Linux. To this end, the code tree has been 
reorganized in two major sections, the first one contains the kernel-related sources 
(ksrc/), the other is hosting the user-space support (src/). Since the user-space portion 
does not need to know about the kernel sources anymore, several issues have been solved in 
the same move. All in all, things are way simpler than before, which seems to indicate 
that we are heading to the right direction. The documentation for the installation process 
needs to be updated though.

o Also as a matter of build system (and a bit more), v2.1 has been backported to Linux 
2.4, starting with the ppc32 support. We rely on Denx's 2_4-devel tree as our 2.4 kernel 
of reference for this port [1]. A second backport to 2.4/x86 will happen when this combo 
is I-pipe ready. We are ahead of schedule regarding this backport, since it was initially 
planned for Q12006, but since we are going to add more supported architectures in the next 
months, it's better to have a stable build system for that.

o PowerPC-wise (again), we should be close to ready for 2.6.15, since Heikki merged both 
the 32 and 64-bit trees in a single one.

All other tasks planned are undergoing. For my part, I'm going to fiddle now with ADI's 
Blackfin for which we already have the required Adeos support, and create the Xenomai port 
for it. Since this one is uClinux based, we should be able to check that the new build 
system is ok to host any kind of port sanely.

[1] http://www.denx.de/en/Software/CVS/

-- 

Philippe.

Re: [Xenomai-core] v2.1 status

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

Philippe Gerum wrote:
> 
> Here is an update regarding the way things progress on the v2.1 branch:
> 
> o The build system has been deeply revamped, so that we now fully leave
> the burden of building Xenomai's kernel support to Linux. To this end,
> the code tree has been reorganized in two major sections, the first one
> contains the kernel-related sources (ksrc/), the other is hosting the
> user-space support (src/). Since the user-space portion does not need to
> know about the kernel sources anymore, several issues have been solved
> in the same move. All in all, things are way simpler than before, which
> seems to indicate that we are heading to the right direction. The
> documentation for the installation process needs to be updated though.
> 
> o Also as a matter of build system (and a bit more), v2.1 has been
> backported to Linux 2.4, starting with the ppc32 support. We rely on
> Denx's 2_4-devel tree as our 2.4 kernel of reference for this port [1].
> A second backport to 2.4/x86 will happen when this combo is I-pipe
> ready. We are ahead of schedule regarding this backport, since it was
> initially planned for Q12006, but since we are going to add more
> supported architectures in the next months, it's better to have a stable
> build system for that.
> 
> o PowerPC-wise (again), we should be close to ready for 2.6.15, since
> Heikki merged both the 32 and 64-bit trees in a single one.
> 
> All other tasks planned are undergoing. For my part, I'm going to fiddle
> now with ADI's Blackfin for which we already have the required Adeos
> support, and create the Xenomai port for it. Since this one is uClinux
> based, we should be able to check that the new build system is ok to
> host any kind of port sanely.
> 

Question: On recent roadmaps I'm so far missing the topic "RT-signal
support in userspace". Are there any concrete schedules (Qx 200y)?

I think to remember that you said Adeos would be involved in such an
extension. Maybe it would be a good time to think about this also when
we extend the Adeos API by shareable IRQs.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] v2.1 status

[Philippe Gerum]

Jan Kiszka wrote:
> 
> 
> Question: On recent roadmaps I'm so far missing the topic "RT-signal
> support in userspace". Are there any concrete schedules (Qx 200y)?
>

Not currently, even if AFAIC, this is an interesting feature to have, so
that we don't always have to process async events over dedicated server
threads in user-space. But, I'm cowardly entirely leaving the core
design issues to Gilles regarding this; I need to keep focused on the
other pending stuff for now.

> I think to remember that you said Adeos would be involved in such an
> extension. Maybe it would be a good time to think about this also when
> we extend the Adeos API by shareable IRQs.
> 

Likely, yes.

-- 

Philippe.

Re: [Xenomai-core] v2.1 status

[Ignacio García Pérez]

I had a first contact with the new build system. I really really don't
like the fact it touches my kernel source tree. Besides adeos, I like to
keep the kernel source independent of xenomai, because that tree is
shared for other projects.

Also, why does it default to monolithic build of the xeno modules when
in 2.0 you always got them as modules?.

Re: [Xenomai-core] v2.1 status

[Wolfgang Grandegger]

[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]

Philippe Gerum wrote:
> 
> Here is an update regarding the way things progress on the v2.1 branch:
> 
> o The build system has been deeply revamped, so that we now fully leave 
> the burden of building Xenomai's kernel support to Linux. To this end, 
> the code tree has been reorganized in two major sections, the first one 
> contains the kernel-related sources (ksrc/), the other is hosting the 
> user-space support (src/). Since the user-space portion does not need to 
> know about the kernel sources anymore, several issues have been solved 
> in the same move. All in all, things are way simpler than before, which 
> seems to indicate that we are heading to the right direction. The 
> documentation for the installation process needs to be updated though.

I like it a lot.

> o Also as a matter of build system (and a bit more), v2.1 has been 
> backported to Linux 2.4, starting with the ppc32 support. We rely on 
> Denx's 2_4-devel tree as our 2.4 kernel of reference for this port [1]. 
> A second backport to 2.4/x86 will happen when this combo is I-pipe 
> ready. We are ahead of schedule regarding this backport, since it was 
> initially planned for Q12006, but since we are going to add more 
> supported architectures in the next months, it's better to have a stable 
> build system for that.

Just tested Xenomai with adeos-ipipe-2.4.25-ppc-denx-0.9-02.patch on a 
recent DENX kernel tree. MPC 8xx support was missing. I have attached
the patch to fix it. Furthermore I have not found the "Machine" options 
(here from 2.6):

  #
  # Machine
  #
  # CONFIG_XENO_HW_FPU is not set
  CONFIG_XENO_HW_PERIODIC_TIMER=y
  CONFIG_XENO_HW_TIMER_LATENCY=1
  CONFIG_XENO_HW_SCHED_LATENCY=1
 

The latency figures on my TQM860L board with Xenomai 2.1 and Liunx 2.4 
are close to the one I measured with Xenomail 2.0 with Linux 2.6:

LATENCY with load on TQM860L:

Linux   |-----lat min|-----lat avg|-----latmax|-overrun|---test-time
2.6.13  |       60480|      120960|     224320|       0|    00:09:46
2.4.25  |       64080|       95120|     225040|       0|    00:10:00


> o PowerPC-wise (again), we should be close to ready for 2.6.15, since 
> Heikki merged both the 32 and 64-bit trees in a single one.
> 
> All other tasks planned are undergoing. For my part, I'm going to fiddle 
> now with ADI's Blackfin for which we already have the required Adeos 
> support, and create the Xenomai port for it. Since this one is uClinux 
> based, we should be able to check that the new build system is ok to 
> host any kind of port sanely.
> 
> [1] http://www.denx.de/en/Software/CVS/

Thanks.

Have a nice weekend.

Wolfgang.



[-- Attachment #2: adeos-ipipe-2.4.25-ppc-denx-0.9-02-8xx.patch --]
[-- Type: text/x-patch, Size: 998 bytes --]

+ diff -u linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S.IPIPE2 linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S
--- linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S.IPIPE2	2005-02-13 21:04:14.000000000 +0100
+++ linuxppc_2_4_devel-2005-11-19_1437-ipipe/arch/ppc/kernel/head_8xx.S	2005-11-19 14:51:27.000000000 +0100
@@ -231,7 +231,11 @@
 	bl	transfer_to_handler
 	.globl	do_IRQ_intercept
 do_IRQ_intercept:
-	.long	do_IRQ;
+#ifdef CONFIG_IPIPE
+	.long   __ipipe_grab_irq
+#else /* !CONFIG_IPIPE */
+	.long	do_IRQ
+#endif /* CONFIG_IPIPE */
 	.long	ret_from_intercept
 
 /* Alignment exception */
@@ -268,7 +272,11 @@
 	bl	transfer_to_handler
 	.globl	timer_interrupt_intercept
 timer_interrupt_intercept:
-	.long	timer_interrupt
+#ifdef CONFIG_IPIPE
+	.long   __ipipe_grab_timer
+#else /* !CONFIG_IPIPE */
+	.long   timer_interrupt
+#endif /* CONFIG_IPIPE */
 	.long	ret_from_intercept
 
 	STD_EXCEPTION(0xa00, Trap_0a, UnknownException)

Re: [Xenomai-core] v2.1 status

[Philippe Gerum]

Ignacio García Pérez wrote:
> I had a first contact with the new build system. I really really don't
> like the fact it touches my kernel source tree. Besides adeos, I like to
> keep the kernel source independent of xenomai, because that tree is
> shared for other projects.
>

At that point, I would really consider leaving the burden of keeping 
various users of a single code base in sync to a SCM, not to the filesystem.

> Also, why does it default to monolithic build of the xeno modules when
> in 2.0 you always got them as modules?.
> 
> 

Because it's a reasonable default:

o Most setups don't need to unload the real-time support, but rather 
load it once for all at startup.
o Given #1, in the embedded space, modules are often considered as pure 
annoyance. Among other things, you need to activate the module support 
in the kernel just to load the RT system once, and this does not come 
for free, especially in terms of memory footprints.
o Modules are allocated in vmalloc space. Given that the vanilla kernel 
already has rather poor code locality (spatially speaking at least), 
things are not going to improve for time-critical code in modules which 
increase TLB misses.

For the rare cases where the arguments above are outweight by a strong 
requirement to have modules, you can still switch them on in your kernel 
configuration; this is the kind of flexibility you did not have with the 
previous build system.

-- 

Philippe.

Re: [Xenomai-core] v2.1 status

[Philippe Gerum]

Wolfgang Grandegger wrote:
> Philippe Gerum wrote:
> 
>>
>> Here is an update regarding the way things progress on the v2.1 branch:
>>
>> o The build system has been deeply revamped, so that we now fully 
>> leave the burden of building Xenomai's kernel support to Linux. To 
>> this end, the code tree has been reorganized in two major sections, 
>> the first one contains the kernel-related sources (ksrc/), the other 
>> is hosting the user-space support (src/). Since the user-space portion 
>> does not need to know about the kernel sources anymore, several issues 
>> have been solved in the same move. All in all, things are way simpler 
>> than before, which seems to indicate that we are heading to the right 
>> direction. The documentation for the installation process needs to be 
>> updated though.
> 
> 
> I like it a lot.
> 
>> o Also as a matter of build system (and a bit more), v2.1 has been 
>> backported to Linux 2.4, starting with the ppc32 support. We rely on 
>> Denx's 2_4-devel tree as our 2.4 kernel of reference for this port 
>> [1]. A second backport to 2.4/x86 will happen when this combo is 
>> I-pipe ready. We are ahead of schedule regarding this backport, since 
>> it was initially planned for Q12006, but since we are going to add 
>> more supported architectures in the next months, it's better to have a 
>> stable build system for that.
> 
> 
> Just tested Xenomai with adeos-ipipe-2.4.25-ppc-denx-0.9-02.patch on a 
> recent DENX kernel tree. MPC 8xx support was missing. I have attached
> the patch to fix it. Furthermore I have not found the "Machine" options 

Applied, thanks. 0.9-03 contains this fix.

> (here from 2.6):
> 
>  #
>  # Machine
>  #
>  # CONFIG_XENO_HW_FPU is not set
>  CONFIG_XENO_HW_PERIODIC_TIMER=y
>  CONFIG_XENO_HW_TIMER_LATENCY=1
>  CONFIG_XENO_HW_SCHED_LATENCY=1
> 

Now fixed.

> 
> The latency figures on my TQM860L board with Xenomai 2.1 and Liunx 2.4 
> are close to the one I measured with Xenomail 2.0 with Linux 2.6:
> 
> LATENCY with load on TQM860L:
> 
> Linux   |-----lat min|-----lat avg|-----latmax|-overrun|---test-time
> 2.6.13  |       60480|      120960|     224320|       0|    00:09:46
> 2.4.25  |       64080|       95120|     225040|       0|    00:10:00
> 
> 

Same observation here on a Freescale Icecube. I will reactivate the 
kernel-space latency test in order to have the full picture.

Thanks,

-- 

Philippe.