On Mon, 2007-02-19 at 13:46 +0100, Dmitry Adamushko wrote: > On 19/02/07, Philippe Gerum <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-02-19 at 13:13 +0100, Dmitry Adamushko wrote: > > > > > ... > > > > > #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. > > Oh yep :) Don't think it's a problem then. SMP && MODULE should be ok. >
Fixed, thanks. > > -- > > Philippe. > > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
