Am 05.10.2010 13:06, Jan Kiszka wrote:
> 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,
I totally forgot that RTDM does not expose any interface to specify the
task stack size. So the user will not notice the difference directly
(but the available stack will shrink).
> 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