Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [PATCH 1/3] stack overflow safe kdump (2.6.18-rc1-i386) - safe_smp_processor_id | Date | Tue, 11 Jul 2006 13:41:03 -0600 |
| |
James Bottomley <James.Bottomley@SteelEye.com> writes:
> On Mon, 2006-07-10 at 21:42 -0600, Eric W. Biederman wrote: >> But I do agree the subarch header files are clean. >> And no this case except for the fact no one realized that the >> code doesn't even compile on voyager does not show how brittle >> the x86 subarch code is. Except for the fact that it seems >> obvious that kernel/smp.c is generic code that every smp subarch >> would use. > > OK ... that's the mistaken assumption. kernel/smp.c is not subarch > generic, it's APIC specific. So all apic using subarchs, which is > pretty much everything except voyager, use it. Since voyager uses > vic/qic based smp harness, it has its own version of this file (in fact > voyager has a completely separate SMP HAL).
Yep. My point is that with the current subarch structure on x86 it is really easy to make mistaken assumptions like kernel/smp.c applies to all x86 subarchitectures, because the lines are not clear. The architectures where I have seen that the lines are clear generally allow for building a single kernel that can boot on any subarch.
My hope is that we can recognized how non-obvious the x86 subarch code is so that future work will be able to improve the situation.
To give credit I do think the division of labor between the subarch's appears sound. I just don't like how the subarches are glued together into the x86 arch.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |