From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Xenomai core <Xenomai-core@domain.hid>
Subject: Re: [Xenomai-core] Overcoming the "foreign" stack
Date: Tue, 05 Oct 2010 13:06:46 +0200 [thread overview]
Message-ID: <4CAB06C6.1090303@domain.hid> (raw)
In-Reply-To: <4CAB0519.1000004@domain.hid>
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).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2010-10-05 11:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-05 9:32 [Xenomai-core] Overcoming the "foreign" stack Jan Kiszka
2010-10-05 9:56 ` Gilles Chanteperdrix
2010-10-05 10:25 ` Jan Kiszka
2010-10-05 10:32 ` Gilles Chanteperdrix
2010-10-05 10:38 ` Jan Kiszka
2010-10-05 10:51 ` Gilles Chanteperdrix
2010-10-05 10:59 ` Gilles Chanteperdrix
2010-10-05 11:06 ` Jan Kiszka [this message]
2010-10-05 11:27 ` Jan Kiszka
2010-10-05 13:15 ` Gilles Chanteperdrix
2010-10-05 13:35 ` Jan Kiszka
2010-10-05 13:42 ` Gilles Chanteperdrix
2010-10-05 13:46 ` Jan Kiszka
2010-10-05 13:50 ` Gilles Chanteperdrix
2010-10-05 14:04 ` Jan Kiszka
2010-10-05 14:21 ` Gilles Chanteperdrix
2010-10-06 9:20 ` Jan Kiszka
2010-10-07 17:08 ` Philippe Gerum
2010-10-07 17:34 ` Jan Kiszka
2010-10-07 18:12 ` Gilles Chanteperdrix
2010-10-07 18:56 ` Jan Kiszka
2010-10-07 20:48 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CAB06C6.1090303@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Xenomai-core@domain.hid \
--cc=gilles.chanteperdrix@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.