Am 05.10.2010 12:59, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> My key question is currently if and how much of this could be realized
>> in 2.6. Could we drop in-kernel skins in that version? If not, what
>> about disabling them by default, converting RTDM tasks to a
>> kthread-based approach, and enabling tracing etc. only in that case?
>> However, this might be a bit fragile unless we can establish
>> compile-time or run-time requirements negotiation between Adeos and its
>> users (Xenomai) about the stack model.
> Just to clarify about 2.6. 2.6 is supposed to have a short-lived
> "unstable" state, where we implement fixes for the few problems on the
> 2.5 branch which require breaking the ABI. So, removing kernel-space
> threads for other skins than RTDM is not the plan. However, does it
> really matter whether other skins than RTDM use kernel-space threads for
> changing the way kernel-space threads stacks are allocated?

Not if we break the API for all in-kernel skins (not only RTDM) by
freezing the stack size (that will be the side effect of moving over
kthreads). I've no problem to do this for RTDM, but in-kernel
applications may have different stack footprints than ordinary RTDM
drivers, thus could break subtly. Therefore the consideration to do a
hard cut then, forcing remaining users to port now (instead of fixing
once again and port later on).


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to