Dmitry Adamushko wrote:2008/7/29 Peter Oruba <peter.oruba@xxxxxxx>:Fixed coding style issues.
I have a comment on the abstraction layer (microcode_ops).
[ Not that I've looked very carefully at it so far, nor I pretend to
be at-ease with this 'microcode' topic to make any design judgements
:-) ]
but would it be somehow possible to not have set_cpus_allowed_ptr()
code in arch-dependent parts? Let's say the mechanism of how to run
certain arch-specific code (and synchronization) on a given cpu should
be a prerogative of (and placed in) the generic part...
Note, this code will likely happily give you an oops if you run
cpu_down/up() ;-)
I also wondered, is there a requirement that when a new cpu is brought
up, microcode updates {should,must} be done as early as possible, say
before any tasks have a chance to run on it? Or can the update be a
bit delayed? e.g. we don't do it from cpu-hotplug handlers.
Dmitry looks like you missed my email. I already asked that question and proposed a couple of options (workqueue and ipi).
Tigran said that he does not know. Maybe Peter does.
My guess is that it does not have to be done synchronously and can be delayed. There is no guaranty that microcode CPU hotplug handler will run before all the other handlers. Which by definition means that some things will start running on the cpu before the microcode is updated. Hence we might as well do the update outside of the cpu hotplug path.
Max