On Fri, Nov 12, 2010 at 07:05:34PM +0200, Antti Kantee wrote: > On Fri Nov 12 2010 at 15:25:04 +0100, Johnny Billquist wrote: > > >Freeway design is not driven by the requirements of the horse. If a horse > > >occasionally wants to gallop down a freeway, we're happy to let it as long > > >as it doesn't cause any impediment to the actual users of the freeway. > > > > > >Over 15 years ago NetBSD had a possibility to take everyone into account > > >since everyone was more or less on the same line. This is no longer true. > > >If old architectures can continue to be supported, awesome, but they may > > >in no way dictate MI design decisions which hold back the capabilities > > >of modern day architectures. > > > > So what you are arguing is that MI needn't be so much MI anymore, and > > that supporting anything more than mainstream today is more to be > > considered a lucky accident than a desired goal?
No, Andrew didn't say that. On the other hand, he did point out that it may not be possible to provide *efficient* machine-independent abstractions to perform operations that were exotic, uncommmon, or simply unheard of when very old architectures were designed. Why is this surprising? Hardware design progresses, and it's silly to think that the only type of advances that will occur will be the type that can be efficiently emulated by some older functionality. Ought we simply not use new hardware features? You are ultimately asking for *more* machine-dependent code in NetBSD, not less -- since, for example, you want to use insque/remque, which would make all sorts of currently MI datastructures MD. The basic problem with VAX, and a few other old or unusual architectures, is that they cannot efficiently implement certain MI abstractions that are well suited to most architectures we support. Causing there to be less MI code, and more MD code, in the tree in order to accomodate that is not a good idea. Now you're going to say "pick better MI abstractions". Guess what? Those do not always exist. No matter how much one might wish they did. > You can try to twist my words in any way that pleases you. However, the > fact is that people who put forward a heroic effort in modernizing NetBSD > will not be held accountable for making sure prehistoric architectures > keep up (*). Some of our older ports have active supporters who keep > the port up to speed with MI changes, set up emulator support, publish > test run results etc. These ports will continue to be supported by > NetBSD indefinitely. What Antti said. And, further, I would like to point out that you (Johnny) didn't step forward and resuscitate VAX support in GCC -- one of the same NetBSD developers you're lambasting for not caring enough about whether old architectures work did so. After the GCC project itself simply abandoned VAX support. Another NetBSD developer brought PCC back to life, so you even have a choice of compilers! A *huge* amount of work goes into keeping old hardware working in NetBSD. You may not like the best-we-can-do results, but it is profoundly rude to attack us for trying. The claim that NetBSD only cares about x86 is even more absurd. NetBSD supports a huge array of architectures, usually in both their modern and ancient implementations. We'll run on everything from R2000 to the newest multicore 64-bit MIPS processors; a similar range of support exists for ARM, powerpc, and many other processor and system families. We have not done as good a job keeping up with SPARC or the death-rattle models of 68k but we certainly haven't ripped SPARC or 68k support out either -- nor does anyone intend to do so. What *is* the case is that when one chooses datastructures and algorithms suited to *most processors currently available* or even *most processors ever supported by NetBSD, in terms of installed systems and possibly at all*, some older architectures suffer worse than others. You keep dodging the question of whether it would somehow be better to make most NetBSD users suffer rather than a few, generally by suggesting NetBSD developers have a responsibility to magically ensure nobody suffers. There is no magic. Get used to it. A lot of hard work has gone into minimizing this kind of suffering, and it's work nobody is being paid to do, either. Please do not yell at the people doing that work. It is likely the case that an older version of NetBSD with *less* MI abstractions in the areas of bus access, memory management, synchronization, etc. would be better suited to your needs. Some people here have perhaps been less than gentle in telling you so. I'm sorry about that. But, nonetheless, please do not yell at us for doing the best we can to keep modern NetBSD working for you at all. Thor
