From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4CAAF0CA.7060603@domain.hid> Date: Tue, 05 Oct 2010 11:32:58 +0200 From: Jan Kiszka MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Xenomai-core] Overcoming the "foreign" stack List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xenomai core Hi, quite a few limitations and complications of using Linux services over non-Linux domains relate to potentially invalid "current" and "thread_info". The non-Linux domain could maintain their own kernel stacks while Linux tend to derive current and thread_info from the stack pointer. This is not an issue anymore on x86-64 (both states are stored in per-cpu variables) but other archs (e.g. x86-32 or ARM) still use the stack and may continue to do so. I just looked into this thing again as I'm evaluating ways to exploit the kernel's tracing framework also under Xenomai. Unfortunately, it does a lot of fiddling with preempt_count and need_resched, so patching it for Xenomai use would become a maintenance nightmare. An alternative, also for other use cases like kgdb and probably perf, is to get rid of our dependency on home-grown stacks. I think we are on that way already as in-kernel skins have been deprecated. The only remaining user after them will be RTDM driver tasks. But I think those could simply become in-kernel shadows of kthreads which would bind their stacks to what Linux provides. Moreover, Xenomai could start updating "current" and "thread_info" on context switches (unless this already happens implicitly). That would give us proper contexts for system-level tracing and profiling. 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. Comments, ideas? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux