[Xenomai-core] Xenomai v2.3-rc1

[Xenomai-core] Xenomai v2.3-rc1

[Philippe Gerum]

Here is the first candidate release for the v2.3.x branch, which
should lead us to 2.3 final, after some iterations. A RTDM-compliant
CAN driver stack is likely the most significant addition to this
release, along with tons of local improvements and bugfixes all over
the map. Short (and non-exhaustive) log follows:

	[nucleus]

	* Introduce the aperiodic timer wheel as an alternative to
	binary heaps for efficiently handling a significant number of
	outstanding timers.

	* Don't send migration or deletion signals to dormant threads.

	* Check for wait abort in xnsynch_sleep_on(). Fully refactor
	the resource stealing feature.

	* Make sure xnsynch_flush() does not alter ownership.

	* Allow sharing the timer IRQ (basically for ARM).

	* Iron mode transition using the TASK_NOWAKEUP support
	whenever available from the I-pipe.

	* Optimize syscall propagation using the new PF_EVNOTIFY
	per-task filter.

	* Streamline nucleus SMP lock implementation.

	* Introduce generic support for runtime statistics (xnstat).

	* Refactor locking code in interrupt support. Improve
	shared interrupt code. Use generic support for runtime
	accounting.

	* Rework the watchdog support.

	[uvm]

	* Feature removed.

	[testsuite]

	* Add IRQ benchmark program.

	* Improve tests output.

	[scripts]

	* Fix modular build for 2.4.

	[hal]

	* x86: Prevent the 2.4 speaker support from perturbating
	Xenomai's TSC emulation code.

	* ppc: Port over 2.6.18.

	* arm: Upgrade Adeos support.

	[native]

	* Fix rt_queue_read() timeout.

	* Fix rt_queue_send() upon null broadcast (wrong reference
	count).

	[rtdm]

	* Enhance non-RT locking during /proc access.

	* Add rtdm_iomap_to_user() service.

	[posix]

	* Fix mutex attribute handling from user-space.

	* Properly handle cancellation requests in
	pthread_cond_wait().

	* Add the --enable-posix-auto-mlockall option to the main
	configure script.

	* Allow sched_yield() to pick secondary mode threads when
	SCHED_OTHER is in effect.

	* Make the timer management better conform to the
	POSIX spec.

	* Make pthread_join() callable from module init/cleanup
	routines.

	[drivers]

	* Refactor RTDM types for timeout and dates.

	* Add RT-Socket-CAN, a RTDM compliant driver for CAN devices.


As a sidenote, please note that this branch will be the first one to
support the latest Linux kernels (>= 2.6.18).

See the ChangeLog for details.

http://download.gna.org/xenomai/testing/xenomai-2.3-rc1.tar.bz2

-- 
Philippe.

[Xenomai-core] Re: [Xenomai-help] Xenomai v2.3-rc1

[Jan Kiszka]

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

Philippe Gerum wrote:
> 	[testsuite]
> 
> 	* Add IRQ benchmark program.

Actually, that test was introduced with 2.2, but now the parallel port
mode works as well (over LapLink-like cables). Particularly useful for
benchmarking notebooks that stopped providing serial ports these days.

Jan


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

Re: [Xenomai-help] Xenomai v2.3-rc1

[Thomas Necker]

> 	[uvm]
>
> 	* Feature removed.
>

I see that there is no direct syscall interface for pSOS added.
We had a discussion about that a while ago. We're still thinking
about doing that ourselves but wanted to use the uvm for the
prototype. Why is the uvm support removed without having
an adequate substitute for the skins it still supports? This
means that there will be no way of supporting pSOS programs
in 2.3, right?

Thomas

Re: [Xenomai-help] Xenomai v2.3-rc1

[Philippe Gerum]

On Mon, 2006-11-06 at 18:34 +0100, Thomas Necker wrote:
> > 	[uvm]
> >
> > 	* Feature removed.
> >
> 
> I see that there is no direct syscall interface for pSOS added.
> We had a discussion about that a while ago. We're still thinking
> about doing that ourselves but wanted to use the uvm for the
> prototype. Why is the uvm support removed without having
> an adequate substitute for the skins it still supports?

Because the UVM introduced a significant amount of issues and confusion
among users for all previous releases, which translated into way too
much maintenance pressure on me, only to work-around unfixable design
flaws. Keeping the UVM alive for the 2.3 series would be the wrong
signal to send, since more people would rely on it, albeit it has been
deprecated during the 2.2 series. In the same time, blocking the release
of the 2.3 series, until the user-space support for pSOS and uITRON
emulators is reinstated would be inconsequent, given the number of
improvements and long awaited features 2.3 provides, like RTCAN.

Sometimes, there is the need to pick a choice among two sub-optimal
options, and this is what I did. This does _not_ mean that the pSOS or
uITRON support in user-space are being withdrawn, only that we need to
deal with priorities, and balance them according to the workforce we
have to develop this project. In the absence of external contribution,
those emulators will be adapted to the direct syscall interface when
time allows.

>  This
> means that there will be no way of supporting pSOS programs
> in 2.3, right?
> 

No, this means that currently, the first -rc releases of the 2.3 series
only support kernel-based pSOS applications. As I told you recently, I'm
ok to provide some help to anyone willing to contribute the direct
syscall interface for pSOS, which would enable a much more reliable
user-space support for this skin, like the VxWorks and VRTX emulators
already benefit from. Doing so would raise the priority of this task on
my todo list. If this support comes early enough, it could even be
merged before 2.3 final is out, since this is a simple and
self-contained add-on with zero impact on the core system.

For the time being, you could still use the UVM support still available
from 2.2.5 for prototyping your application, provided you likely don't
depend on 2.3-specific features like RTCAN drivers, since they would not
mix well with a UVM environment anyway.

> Thomas
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.