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 | Mon, 10 Jul 2006 21:42:09 -0600 |
| |
James Bottomley <James.Bottomley@SteelEye.com> writes:
> >> To some extent this also shows the mess that the x86 subarch code is >> because it is never clear if code is implemented in a subarchitecture >> or not. > > Erm, it does? How? My statement is that introducing subarch specific > #defines into subarch independent header files is a problem (which it > is). If you grep for subarch defines in the rest of the arch > independent headers, I don't believe you'll find any. This would rather > tend to show that for the last seven years, the subarch interface has > been remarkably effective ....
They are remarkably brittle, because it is very hard to tell which code is in a subarch and which code is not. There have been several iterations where people have broken subarchitectures by mistake.
This whole conversation is funny in one sense because the code under discussion won't even compile on voyager right now. Someone else caught that and the patch that came out of that conversation was sent to Andrew earlier today.
All I know for certain is that I have submitted patches that have changed the entire kernel and the only thing that broke was x86 subarches because it is so non-obvious how they are different.
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.
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/
| |