Re: debootstrapping m68k-coldfire
On Sat, Mar 01, 2008 at 11:50:08PM -0500, Michael Casadevall wrote:
> 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 disagree. I explained why in a reply to Roman's mail, but before it
got sent out, my laptop's hard disk died on me. Perhaps I'll still be
able to recover that, but I'm not sure.
Anyway, the problem isn't that bootstrapping coldfire is hard; I can do
that myself if needs be, and we'd have a working port within a few
months[1]. The problem is that adding another port isn't going to be
accepted by FTP masters: I don't recall who exactly, but an FTP master
did tell me that a coldfire port in Debian would only be accepted if it
was either part of the m68k port, or replaced it entirely.
To me, the latter is not acceptable, so that leaves us with the former.
You did raise a point that arm was able to have two or three ports in
the archive. This is not correct: the armel port is only accepted
because it was made clear that the arm port will be dropped after lenny;
and the armeb port, for which I've done some buildd work in the past, is
now well and truly dead. A second example is the SH port: that got
killed off because the SH porters found that the only way to proceed
forward was to split the port into two (or four) different ports, and
that was not accepted.
> 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
- Debian is not Gentoo. Optimization is cool if we can do it, but it
should not be an argument for or against doing something.
- AIUI, with a working TLS implementation it is possible to compile an
optimized library, and store it under /lib/tls/<something> so that the
dynamic linker will pick it up depending on the subarchitecture you're
running on. This will not make the optimization problem go away, but
will at least mitigate it.
> * 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
These two are correct.
> 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).
These also hold for any hybrid port.
> * 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.
Correct, but only as far as ColdFire goes. If we have two separate
ports, then the m68k port itself will not get that interest from
Freescale or anyone else.
My main reason for asking for the ColdFire boards was so that the m68k
port could be spared from eventual, but certain, death. By creating a
separate ColdFire port, this goal will not be achieved.
Now if everyone thinks this is the right thing to do, then I won't
object. But I just don't think it /is/ the right thing to do.
Something else: I contacted Andrew Pollock, who once offered to ask
within Google whether Debian people could hold meetings there, and he
replied, confirming that this is still possible. The only problem, of
course, is going to be the timezone issue: it's going to be possible to
get us inside a Google campus, and hooked up with eachother through
teleconferencing equipment; it's not going to be so easy to do this at
3AM local time, however. The best I seem to be able to find is to have
something start at 21:00 in Europe, which is 07:00 in Sydney and 15:00
in New York (the US time could of course differ depending on the exact
campus used there). That requires staying up late in Europe and getting
up early down under; but everything else is far worse.
Thoughts are welcome.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: