[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debootstrapping m68k-coldfire

I do realize I'm the new guy here, but I do have an outside perspective, and I do hope I'm not getting out of line here.

On Wed, 5 Mar 2008, Finn Thain wrote:

On Tue, 4 Mar 2008, Wouter Verhelst wrote:

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.

The problem here is that they are considering m68k and coldfire to be the same architecutre; sorta like i386, i486, and i586. The fact that freescale/Motorola considers it a seperate architecture, and offers migration tools (similar to i386 -> Ithiumiun, or the aborted i386 -> alpha of old), is enough in my book to consider it a seperate architecture; if it is unable able to run binaries straight from m68k with no modification beyond the kernel or glibc library, that's enough to consider it a seperate architecture.

I'm going to play devil's advocate here for a moment; from the release manager perspective, does it pay to release two ports, one for (there perspective) a dead architecture like m68k (popcon lists 10 users, and I know three of them are my machines), and another for an embedded architecture. As it stands, the RMs are hestinate to have an embedded architecture released; the only reason armeb was blessed as an offical port was because NSLU2 users using armeb enabled popcon which provided the justifcation; the armeb port has appartantly bitten the dust since the issues with the NSLU2 network card in little endian mode were resolved.

As a user of Debain on not only ARM, but on my MIPS router (with NFS), it works beatifully on an embedded system as long as you have drivespace (granted, APT can be slow at times, but its a one time operation, I'm not going to be complaing much; truely embedded distros like OpenWRT use ipkg for this reason).

To me, a hybrid is not acceptable and the old should indeed gracefully bow
out and make way for the new. But, without user demand for CF, it is all

The problem with generating this that 90% (I'd go even as far as 95%) percent of coldfire boards in existance do not have the required MMU a Debian port would require. Only a handful of coldfire v4s have the MMU chip (I think the v5 does too, but I'm not sure offhand). At best, any coldfire port we'd do requiring glibc and a full MMU Linux will only be usable by a subset of users. I suggested we do a uclibc-coldfire port, but I've been told there would be issues on the number of libraries we'd have to compile and use.

For myself, I'd switch to gentoo which doesn't have the infrastructure
overhead, and keep the old alive that way. Has anyone considered
addressing debian's infrastructure requirements? Is it not in Debian's
interest to encourage more spin-off distros?

If we have two separate ports, then the m68k port itself will not get
that interest from Freescale or anyone else.

How do you support that assertion?

At least from my perspective, coldfire and m68k are seperate architectures, but from a compiler perspective, they aren't; assembler code for one will more or less work on the other with some exceptions. Any work done towards coldfire will be usable with minor tweaking in a worse case scenario on classic m68k.

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.

It seems to me that if a hybrid could save our port, so can aranym (at
least until demand for CF justifies the inevitable demise of debian's old
m68k port).

I suspose the question needs to be asked; what are people doing with their old m68ks. Most people around here are using them for (obviously enough) buildds to attack the unstable queue. I popped over to netbsd, which is the only other operating system distro besides Debain and Gentoo to support m68k. The mailing list is completely dead looking at the archive, and the latest NetBSD releases do not offically support any m68k architecture as far as I can tell.

If I had actual m68k hardware, they'd probably be used for something similar to what my NSLU2 right is being used for; file, email (and in my case, wanna-build) servers. The problem is, I really don't see anyone using their hardware for these purposes.

As for saving the port; well, effectively at the moment, we're already dead. No (offical) testing, and I really doubt we're going to see a lenny-m68k branch on the mirrors. The question becomes is resurrecting a. worth it (IMHO, yes, Debian shold support as many architectures as possible), b. fessiable (we were catching up on the unstable queue until my ISP died, so again, I'd say yes), c. allowed by the RM (eh, I'll be honest, I'm not sure if they'd let us re-release; they already appear to consider us dead).


To UNSUBSCRIBE, email to debian-68k-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: