On Mon, Nov 11, 2013 at 08:01:15PM +0100, Alistair Crooks wrote: > > I have no indication before I buy a SoC if it is supported by NetBSD.
I can't see how this, at least, is any worse than it was before. At the end of the day, either we're going to use the absolute LCD feature set for any architecture with multiple generations -- which would leave us running 32-bit MIPS1 code on Octeon, etc. just for the convenience of having "only one userland MIPS port" or we're going to have this kind of profusion of ports per CPU family. It's just a fact of life. ARM in particular, but also MIPS and to some extent PowerPC, have far more variants than our old scheme accounted for. To actually be able to use the features of those variants, there will have to be many more sets of userland binaries. We can pretend otherwise, and get lousy performance and lots of confusion from people building embedded things that actually need the features, or we can bite the bullet and admit there really cannot be a single set of "arm" binaries any longer. It seems to me this is largely a tempest in a teapot that could be dealt with by a simple table, somewhere obvious on the web site, showing the mapping necessary to download a working kernel and binaries for each common CPU (or SoC). Thor