Re: FOSDEM thoughts
CF doesn't strictly have to be a separate port; it simply needs separate
binaries. From a tool chain perspective, coldfire is identical, its
identified as m68k-linux-gnu with the expectation of the binutils
target. Unless a failure to build is triggered by a binutils bug, m68k
and coldfire should be identical once you get higher then pure opcodes
(and if we have any packages that include hand assembled m68k binaries,
I'll eat my boot). It's proof that porting Linux to coldfire was trival;
I don't even think there are any specific options for CF in the actual
kernel.
One of the machines I was going to use as a m68k buildd, proved
unsuitable (it seems lilo in aranym on PPC is broken and I don't know
enough about the Linux kernel/ELF file format to figure out what's
broken without a significant time investment). I could throw
QEMU/Coldfire on it, do the grunt work of porting dpkg to recognize
coldfire as an architecture (right now, all its doing is mirroring
debian etch, and I'm setting up a Testing distro on it. Adding an
incoming and spawning a w-b database for coldfire would be fairly easy).
I was under the impression that five evaluation were given out, might be
worth finally putting those to use :-).
Michael
On Tue, 2008-02-26 at 13:24 +1100, Finn Thain wrote:
>
> On Mon, 25 Feb 2008, Christian T. Steigies wrote:
>
> > > Getting the coldfire port working would be nice, yes... I believe that
> > > would bring in fresh blood and a general boost for debian-68k/cf...
> >
> > We had a discussion with Aurelien, Geert and Sven about coldfire. The
> > consensus was that we should not make cf a separate port, since we would
> > probably loose all m68k developers in that case. I personally am
> > interested in cf only if it can help m68k,
>
> That is my interest too. But surely that argues against your first
> statement about losing developers?
>
> What concerns me is that both 680x0 and CF code would be compromised if
> one port were to try to support both.
>
> I don't know if anyone can confirm this example, but it looks like no-one
> gets to use div without adding compatibility code,
>
> http://acp.atari.org/articles/mcf5407eval/mcf5407eval.html#Modifications%20of%20the%20MiNT%20kernel
>
> It seems to me that since supporting CF will be detrimental to our port in
> terms of performance (especially when compared to aranym as a means to
> help), then it can't fly because 680x0 users just don't have performance
> to burn.
>
> > if I want something "new", I would go powerpc, I need an excuse to get a
> > PS3 ;-) Also we would probably share the fate of arm/armel. armel will
> > be in lenny+1 but arm will be removed after lenny to not further
> > increase the load on the mirrors, I am afraid m68k would be dropped
> > completely if we ask for a new cf port.
>
> Surely it is just a matter of CF reaching critical mass in the market.
> When that happens the necessary developers, hardware and rationale for a
> CF-only port will outweigh the objections of the FTP masters. And surely
> that has no implications for any existing ports.
>
> The fact that Freescale and CodeSourcery have essentially given those
> hypothetical CF-only port users the ABI, and the kernel, C library and
> toolchain ports means that the best way to meet the needs of those
> hypothetical users will be a CF-only port, lest those users miss out on
> what amounts to corporate sponsorship.
>
> And since there can be no binary compatibility between hybrid or CF-only
> code and existing code, I must agree with Michael Casadevall that the best
> way is a seperate port (or none at all in the absence of demand).
>
> IMHO, Aranym means that 680x0 users don't stand to benefit much anymore,
> so let the hypothetical future CF users worry about their own port.
>
> Michael also aluded to the fact that the similarities between the two
> architectures mean that a future CF port will benefit from a healthy 680x0
> port regardless. Likewise, debian-m68k would enjoy "a general boost" (to
> borrow Ingo's words) even from a seperate debian-cf port.
>
> -f
>
>
Reply to: