Re: [PATCH 01/27] smpboot: Provide a generic method to boot secondaryprocessors

[Srivatsa S. Bhat]

On 06/03/2012 05:09 PM, Russell King - ARM Linux wrote:

> On Sun, Jun 03, 2012 at 05:03:50PM +0530, Srivatsa S. Bhat wrote:
>> That's a good point! But unfortunately we can't do that just yet.
>> Because, some architectures have explicit comments that say that
>> irqs must be enabled at a certain point in time, or have something
>> special than just a local_irq_enable(), and hence fall under the
>> __cpu_post_online() function when converted to this model.
>>
>> Examples: ARM (patch 26) and ia64 (patch 15)
>>
>> Unless the maintainers give a go-ahead to change them, I don't
>> think it would be safe.. (I have added the Notes section to each
>> patch to get the attention of the maintainers to such issues).
> 
> I have no intention of touching ARMs SMP bringup any more than is
> absolutely necessary - this code is extremely fragile, and it's taken
> a long time to get it to where it presently is, where most people are
> happy with it.
> 

> Especially problematical is stuff like where we enable interrupts in

> relation to other activities.
> 
> It's probably best to describe the code not as "mostly bug free" but
> as "causes the least pain" because I don't think there is a solution
> which satisfies all the constraints placed upon this code path by
> the various parts of the kernel.
> 


Thanks for your comments Russell. I understand your concerns. So, the
ARM patch does no functional change and retains how and where the
interrupts are enabled. And from looking at what you said above about
the bringup being fragile, I think even in future you wouldn't want any
functional changes to ARM just to make it fit into some generic model.
Thanks for the clarification.

However, what are your thoughts on the existing ARM patch (patch 26)
(which doesn't cause any functional changes)? That shouldn't pose any
problems right?

Regards,
Srivatsa S. Bhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/