Re: Fwd: Time to let sun4m + sun4d RIP?

[Sam Ravnborg <sam@ravnborg.org>]

> 
> 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