On Wed, Aug 09, 2006 at 11:35:21AM +0200, Roman Zippel wrote: > Hi, > > On Fri, 4 Aug 2006, Wouter Verhelst wrote: > > > > Last time I checked the cas instruction is also not available, which > > > makes multithreaded code interesting. > > > > This is an issue I didn't know about yet. It's indeed missing, but I > > didn't know that these instructions were that important. > > > > Can you give me an example of how it's actually used in multithreading? > > I know it's used in libstdc++, possibly other places too. It's the only > way to implement signal safe primitives without kernel traps.
I see. > In this case I'm considering adding a special page to the user process > (similiar to the x86 vsyscall stuff). This would make it possible to > support WildFire (locked and dma accesses don't like each other) and > similiar broken hardware. Right. I'm not even remotely near hacking libstdc++, but when I am, I'll probably give this a closer look. Thanks for pointing this out. > > > A hybrid doesn't automatically fix the toolchain problems and > > > doesn't really make the toolchain maintainance any easier, if it > > > worked for CF it would also work for m68k. > > > > Of course not; I don't think I ever implied that. > > > > However, it would solve several other outstanding problems which we have > > and that have to do with the age of the hardware. This is certainly > > important. > > What problems would that be? Toolchain problems don't solve itself and > the build speed doesn't seem to the biggest problem. [...embedded...] > The problem is that these users are not really visible, could Debian/CF > meet the release requirements on its own? > I'd really prefer to keep this at least initially separate and worry about > a possible merge later. You're not honestly suggesting that we try getting a separate port for Debian/CF, are you? Sure, the build speed is not the biggest problem. Not for now, at least. But that's only because we have bigger problems, not because the build speed isn't a problem at all. The original Vancouver proposal included a clause that no port should require more than two machines to be able to keep up. This was not a joke; they meant it. This requirement is right now not in force only because we could not get to an agreement in Helsinki; I expect it to surface again, given time, if we don't find ourselves a way of increasing the average speed per buildd. Supporting hardware that is no longer being developed requires a lot of resources; not just from Debian/m68k porters, also from other people. The security team has said that it doesn't matter for them whether they need to support 2 ports or 20, as long as the buildd infrastucture works; and while we can do that, the fact remains that requiring 26 hours to build mozilla or firefox will keep all of Debian waiting for us on a firefox security update. To name but one example; there are other examples of software that takes very long to build on our port, but do need to be built for security updates. Supporting a Debian port requires processing time, disk space, and bandwidth on ftp-master.debian.org. Adding the AMD64 port took a few years simply because ftp-master could not cope with the added load of another port on those three levels. In that light, asking for a second m68k-ish port because "not doing this will make 10-year-old hardware run even slower!" isn't going to be much of an argument, especially not if that second port would block some other port that /would/ require a separate compile target. Examples of such ports do exist, and there are a number of people waiting at the gates to be allowed in. Debian/FreeBSD, Debian/armeb, there's even talk of a port to Minix. Supporting a Debian port requires a lot of work from a lot of people. Most of that work got put on our shoulders in Vancouver, but not all of it; it's impossible to do that. The Release Managers all have a lot of work to keep an eye on all the ports; this includes the d-i release managers, the stable release managers, and the "regular" release managers that take care of etch and sid. Getting a second port to get debian to work on ColdFire is totally out of the question. And besides the point, too. Getting Debian/68k to run on ColdFire _will_ solve many problems. It will not magically fix the toolchain, that much is clear; however, it will get us hardware that is much beefier than what we have now, and this is much needed: * We had a buildd park of 12 machines, last I checked; if more than a few of those go down, we start lagging behind again. Due to the age of much of our machines, this happens more often than is the case for, say, amd64. Getting newer and more powerful hardware will mean that we will not have broken hardware as often, and that we may have more surplus capacity than we do now. While we can just add new buildd machines now, too, this isn't the most ideal solution, since adding a new buildd host increases the load on buildd maintainers fairly importantly; the cost/benefit ratio is much better on ColdFire. * If major updates are in order for large sets of packages, wanna-build will queue them in semi-random order, which isn't the most efficient. Since the core libraries take some time to build, the mess remains for a while. It takes quite a bit of work to fix such a mess; if those core libraries are built faster, then the mess is smaller and the number of failed packages and packages in dep-wait will be much, _much_ smaller. * More importantly, currently half of our buildd park are macintoshes that will not work with 2.6 kernels. 2.2 and 2.4 are scheduled to be removed from unstable, a move which will likely occur this month, maybe even this week. It will not take very long before glibc will drop support for 2.2 and 2.4 kernels, mainly because the glibc maintainers were amongst those asking for this change. While we can theoretically keep running our macs on 2.2 kernels and have them build packages, they will fail an ever-increasing number of things, much like the xargs issue that we currently see on a fair number of builds on 2.2 kernels. If our macs cannot run 2.6, we will need to find replacement for these somehow. We do not have the surplus buildd power to just forget about the 2.2-running machines and continue with those machines that do run 2.6. * Having an architecture that is actively being used and sold means that corporate sponsorship, when required, is a possibility. The same is hardly true for the current m68k port. I'm not saying that we absolutely do need corporate sponsorship, but there are times when such sponsorship can help a port tremendously. In addition, this work that I'm doing on the toolchain in support of ColdFire is teaching me a lot about the toolchain itself. Just that, ignoring all of the above, can only be a good thing, right? ;-) That being said, the coldfire stuff is not currently being merged into Debian/68k proper; we are (well, I am) doing this in a subversion repostitory on alioth.debian.org, until the hybrid stuff is mature enough to try and compile the archive with it. Only then will we think of modifying whatever is left of Debian/68k. So, yeah, it'll be at least a few years before Debian/68k will run on ColdFire hardware. Certainly etch (which is planned for December) isn't going to. > > Besides, there are actually amiga upgrades being sold based on ColdFire > > processors. See http://elbox.com/faq_dragon.html and > > http://elbox.com/news_04_12_17.html. That being said, I don't know how > > popular those are, or indeed even if they actually sold any of those > > already. > > Hmm, the oldest news is about one year old and I couldn't find anything in > the online shop. Even for their PCI boards we currently have no kernel > support. Okay, so that's a dead end then, probably. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
