On Mon, 2006-07-10 at 12:20 -0600, Eric W. Biederman wrote: > I agree that it shows the problem, and that voyager is different from the > rest of the x86 implementations.
As a non-apic based SMP implementation, I don't think there was ever any dissent about the latter. > At least for things like the cpumask_t density of processor ids > is still an interesting property. The basic issue is that apicids are > not in general dense on x86. Not being able compile with support > for only two cpus because your cpus happen to be apicid 0 and apicid > 6 by default is an issue. Density or lack of it is pretty much irrelevant nowadays since the CPU map iterators are sparse efficient. Whether x86 PC chooses to avail itself of this or not is the business of the PC subarch maintainers. The vast marjority of non-x86 SMP implementations still have sparse (or at least physical only) CPU maps. > 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 .... > Fernando can you just put a trivial voyager specific definition of > safe_smp_processor_id in mach-voyager/voyager_smp.c. It isn't a fast > path so the little extra overhead of making two separate functions > is not an issue and then the generic header doesn't have to have > subarch breakage. Just a definition of safe_smp_processor_id(). Yes, that should work. James _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
