On Mon, 2007-02-19 at 13:13 +0100, Dmitry Adamushko wrote: > 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.
It's insmod. > 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? > Not sure, unless we explicitely ask the I-pipe to notify us when module_inits terminate. > > > > -- > > Philippe. > > > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
