On 19/02/07, Philippe Gerum <[EMAIL PROTECTED]> wrote:
On Mon, 2007-02-19 at 12:01 +0100, Dmitry Adamushko wrote:
> Hi,
>
> I suppose, that's what happens.
>
> __xeno_sys_init() (./ksrc/nucleus/module.c) which is module_init() and
> when compiled in -> initcall()
>
> calls xnarch_init() (./include/asm-i386/bits/init.h)
>
> This one amongst other things does
>
> ...
> #ifdef CONFIG_SMP
> /* Make sure the init sequence is kept on the same CPU when
> running as a module. */
> set_cpus_allowed(current, cpumask_of_cpu(0));
> #endif /* CONFIG_SMP */
>
> In fact, "running as a module" seems to be a bit
> misleading here. Then another macro should be used in addition,
> MODULE or how it's called.
>
> Now guess who is a "current" here? It's "init" (pid 0).
>
> init() -> do_basic_setup() -> do_initcalls() -> ... ->
> __xeno_sys_init() -> xnarch_init()
>
> "init" is a first process to run and all the rest will inherit its
> "cpus_allowed" field.
>
> That's it.
>
Eh, that's what I call a nice one Dmitry. This is the perfect example of
legacy code stabbing us in the back. We should indeed definitely check
for MODULE && SMP.
Yep, as the very least. But even in this case, it's not very nice that
via cpus_allowed we affect - scheduling-wise - a process which loads
xeno modules and all its children as It's likely to be a shell.
I haven't looked for further details now but isn't it possible to
restore the actual state of "cpus_allowed" right after the init
sequence has been done?
--
Philippe.
--
Best regards,
Dmitry Adamushko
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
