Well, it's been discussed time and again. It's overdue; its time we
bootstrap the coldfire port. Roman convienced me in his email that having
coldfire as a seperate binary distrubution is without a shadow of a doubt
the only SANE way we can support both coldfire and classic m68k. I'm
willing to do the grunt work on bootstrapping the port. I figure I should
try and point out why not old a seperate port is a better way to go, why
it won't kill classic m68k.
Reasons for having a seperate port:
* We can optimize to each specific architecture
* It can be done now; we don't need to keep monkeying around with
binutils.
* We don't need to worry about any weird errors come from the
binaries due to the different opcodes and such
Reasons why the seperate port won't kill us:
* Almost all work done on coldfire can easily be used on classic
m68k; including kernel TLS and glibc porting (assuming CS ever
comes through for us)
* By generating interest in the coldfire port, we can probably
find more people who can fix gcc bugs in not only
coldfire, but classic m68k (the backend code for GCC is pretty
similar; 90% of it is more or less shared, with a few minor
differences).
* Freescale probably going to point to the fact that Debian runs
on coldfire (they did give us evalution boards), and might end
up commiting things towards the project once it gets off the
ground.
If someone will give me access over SSH to one of the coldfire boards, I
will work on cross-building the entire userland for coldfire, and applying
the patches APT will need to recongize coldfire as a seperate
architecture. Any board would need a real linux kernel, busybox, and
dropbear; I can cross-build everything else (and considering I spent most
of the day (attempting) to cross-build the ada compiler, this is trival in
comparsion :-)).
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
