Am 05.10.2010 15:50, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Am 05.10.2010 15:42, Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> 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. >>>>> A stupid question: why not make things the other way around: patch the >>>>> current and current_thread_info functions to be made I-pipe aware and >>>>> use an "ipipe_current" pointer to the current thread task_struct. Of >>>>> course, there are places where the current or current_thread_info macros >>>>> are implemented in assembly, so it may be not simple as it sounds, but >>>>> it would allow to keep 128 Kb stacks if we want. This also means that we >>>>> would have to put a task_struct at the bottom of every Xenomai task. >>>> First of all, overhead vs. maintenance. Either every access to >>>> preempt_count() would require a check for the current domain and its >>>> foreign stack flag, or I would have to patch dozens (if that is enough) >>>> of code sites in the tracer framework. >>> No. I mean we would dereference a pointer named ipipe_current. That is >>> all, no other check. This pointer would be maintained elsewhere. And we >>> modify the "current" macro, like: >>> >>> #ifdef CONFIG_IPIPE >>> extern struct task_struct *ipipe_current; >>> #define current ipipe_current >>> #endif >>> >>> Any calll site gets modified automatically. Or current_thread_info, if >>> it is current_thread_info which is obtained using the stack pointer mask >>> trick. >> >> The stack pointer mask trick only works with fixed-sized stacks, not a >> guaranteed property of in-kernel Xenomai threads. > > Precisely the reason why I propose to replace it with a global variable > reference, or a per-cpu variable for SMP systems.
Then why is Linux not using this in favor of the stack pointer approach on, say, ARM? For sure, we can patch all Adeos-supported archs away from stack-based to per-cpu current & thread_info, but I don't feel comfortable with this in some way invasive approach as well. Well, maybe it's just my personal misperception. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
