Re: Future of m68k - Etch and beyond
On Sun, Feb 25, 2007 at 05:09:00PM +0100, Roman Zippel wrote:
Combining 3 mail replies to one...
> > My question is now:
> > What is the *exact* plan for m68k for Etch and beyond?
> IMO as long as there are few people who have the power to veto m68k out of
> existence, I don't see much further hope for m68k within Debian.
> The absolutely worst mistake was to generally downgrade _all_ m68k
> specific bugs - m68k can't get a realease arch until the bugs are fixed
> and bugs don't get fixed if they are not serious and testing becomes
> useless for m68k. The really bad thing is that whose in power are not even
> open to discuss this [0]. :-(
Yes, I have to agree here as well, especially because the release is delayed
so much, that many of these RC bugs could have been solved in the meantime.
For me it's just a deliberation how to proceed. It doesn't make much sense
to me to keep all of my m68ks running, if Debian and m68k is a dead end.
> > Well, the impression I got from Bills aranym tests are, that it is not
> > much faster than any real m68k hardware.
> Current releases waste a lot of time in the mmu emulation, CVS has
> already some improvement and I'm working on to improve it a bit more.
> With the CVS version I did a simple test with Linux Bogomips value, with
> the improvements the value was about 3.5 times higher and on my P4 3GHz
> system I get about half of the real 68060/50. The bogomips loop is running
> from the icache, so it doesn't include cache misses, while for aranym it's
> relativ constant.
> The next big improvement would be if we had at least some simple JIT -
> just decoding the instruction and then jumping to a subroutine would
> already be a big step.
Well, I see aranym & co just as a last resort for huge backlogs - and as a
possibility to enable other DDs to debug m68k bugs on their home machines.
> > At this point, though, I'm still convinced that it's possible to create
> > a port which will work on both coldfire and "classic" m68k; and with a
> > glibc that has TLS support (which we still need as well), it doesn't
> > even have to slow down things too much (since you can compile optimized
> > libraries where it makes sense, and have the dynamic linker select the
> > right one at runtime).
> It's probably not impossible, but I highly question whether it's really
> desirable. The instructions sets are already quite different and reducing
> it to the smallest common set, does no favour for neither port, as you
> barely can use any advantage either has to offer.
> If this is seriously the only option left for Debian/m68k to survive, I
> will not support it.
Same for me. I don't think that a castrated m68k port will be beneficial to
the users, nor that a emulated-only port will be worth it to be supported.
That said, I think I will shutdown most of my m68ks when Etch will be
released and there's no upgrade path for m68k beyond that point.
OTOH, I would be willing to invest more machines, time and money in keeping
the m68k port alive - regardless of being it a part of Debian or not.
Meaning: with all those political background Debian incorporates, it may be
worth a thought to fork the infrastructure and do our own stuff.
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: 2744150@sipgate.de
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
Reply to: