> On Fri, Mar 09, 2007 at 10:21:33PM -0600, Drew Scott Daniels wrote:
> > I recall reading a better quote about hardware having more problems.
> > Things like bad disks, overheating CPU's, questionable drivers for
> > certain hardware? Certainly there's a case based on speed. Given Bill
> > Allombert's results, and the number of build failures I've seen due to
> > hardware, I think many people think emulation is a good choice. But then
> > this really isn't a d-vote topic. Let's take this to debian-68k if we want
> > to say more.
[...]
What would be useful then is some more metrics I guess.
Some interesting points:
- 68k emulation has been going on for more than 10 years.
- I found a patch for MMU support for UAE and sought out the author (who
was then doing GCC work). He seemed to recall the patch was possibly
useless. This was several years ago though. He also said the cross
compiler would probably be a better alternative, and I should file
bugs if cross compiling didn't work.
- http://www-gatago.com/linux/debian/ports/68k/34992877.html seems to
indicate that even last year there was an MMU bug in ARAnyM (unstable)
that was promptly fixed. This seemingly was when Linux was first
starting to run on it. Another person at that link said Motorola also
made MMU mistakes though.
- The discussion about adding emulated buildds has been going on for
many years now.
I think 10+ years of CPU instruction support (vMac, UAE, Basilisk(2)...)
and a very responsive upstream emulator group make ARAnyM an attractive
alternative when native hardware is too slow or not available. Even when
native hardware is fast enough and available, emulation might provide
additional benefits such as check-pointing.
It is probably useful to compile things on a wide range of hardware in
order to look for driver and hardware problems. That said, finding
problems that are due to hardware failure are probably less useful. It
is nice to know failure modes though. I guess ideally everything would
get compiled on every sufficiently unique system including an emulator.
Practically, some buildd related software would would need to be done to
even use an emulator as a backup unless porters explicitly move hardware
related failures?
If I go much more into this (I probably will), I'll put this stuff into
a wiki page.
Thanks,
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
