> > Is there currently some technical difficulties that prevents us for > keeping the status quo? Or > is this just a suggestion for the sake of suggestions ? sun4m + sun4d is a significant part of the sparc32 architecture. Some quick hacking revealed the following numbers: > 16 files changed, 28 insertions(+), 2958 deletions(-) There are more to come after if we go this route. The stuff I have on the todo list for sparc32 are (in no particular order): - Fix to we map memory correct durign startup. We need to find a way so we map memory such that we do not hit the current limitation where things goes wrong after the kernel becomes slightly too big. - introduce memblock (i have something halfway done, but it fails due to the memory mapping problem. And it did not support highmem) - use proper of_ function for floppy - analyze what can be shared with sparc64, there seems to be more shareable code than what we have today. Especially during startup. - cpu_data.counter is used to display number of NMI interrupts in arch_show_interrupt - this is plain wrong. We do not have any NMI counter on sparc32 - make more sparc drivers buildable on x86 - to get better build coverage - address some of the sparse generated warnings - try to get down to 100 for arch/sparc/ - get qemu running to ease testing (not kernel related) And there are probarly more when I start surfing the code again. The above becomes easier when there are less code to understand, change and eventuelly test. Sam -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
