Subject: Re: CPU_INFO_FOREACH vs mi_cpu_attach().
To: matthew green <email@example.com>
From: Andrew Doran <firstname.lastname@example.org>
Date: 12/18/2007 15:38:08
On Mon, Dec 17, 2007 at 08:59:20AM +1100, matthew green wrote:
> i'm trying to clean up some issues with CPU_INFO_FOREACH() being
> used before all cpus are attached.
> i wonder if there should be some defer method for these calls so
> that cpus attached after it has run can actually do something.
We discussed this offline before. Do you see problems with moving
the call to mi_cpu_attach() for the boot CPU into machine-dependent
code? I think it would fix most of the issues, leaving pool_cache as
the remaining problem area (although we already work around that).
> from my experience so far all these callers are really callers
> of softint_establish(). so, i think that if this function gains
> the ability to defer these setups until just before the point of
> config_interrupts() time, which should be before any of these
> softint's get called.
> another alternative i thought of was to introduce some knowledge
> between mi_cpu_attach() and eg, softint_establish() such that
> mi_cpu_attach() knows what missing calls for each cpu are needed.
> this method would require re-working most of the callers to deal
> with individual cpus (eg, softint_establish() would need to know
> to setup the relevant parts for this cpu.)
I'm not sure what you're proposing. The setup routines called
from mi_cpu_attach (eg xc_init, softint_init) do per-CPU setup.
The first time called they do initial setup, but in all cases they
will copy / setup state for the CPU they have been called for.