> <FUD>
> But not for Intel et al., who'd like x86 binary compatibility, or people
> from device driver companies, who'd like more job security.
> </FUD> :-)
As other people pointed out, Intel is going to introduce
Merced so UDI will need to be multi-platform.
Something other people haven't pointed out yet: UDI will
also have to be multi-bitted, not only in the sense of
32/64 bit, but also little _and_ big endian. This is because
HP will (probably/certainly?) port HP/UX to Merced in a
big endian format while all the other Merced systems will
be little endian.
By now, we will have covered the full spectrum of possible
bit- / endianness-combinations, so there's no stopping UDI
from being implemented on other platforms (SPARC, MIPS, PPC)
too, after all, the UDI drivers are running 'sandboxed' so
all virtual/physical and bus/iobus/membus/cpubus details can
be hidden from it...
(this will also be an advantage to Intel, since that allows
for a larger freedom in the design of the Merced system
architecture, giving possibility of more performance with
less silicon)
The only possible conclusion is that Intel too can only
benefit from full portability; in fact, Intel needs it
too (suppose Intel wants to compete in the SPARC or PPC
business, with UDI they can do that in a commercially
viable way; if the x86 market becomes too crowded and
commercially non-viable, they will want a way out)
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/