It's Sunday night, and I always have screwy suggestions for the world at
the end of the weekend, so bear with me...
And as another worthy collegue noted, these opinions are mine and do not
necesarily represent the stance of my company.
Kevin D. Kissell wrote:
Here at MIPS Technologies, we use Linux internally
for design verification, experiments, benchmarking,
etc., and as a consequence Carsten Langgaard and
myself have both been active in this forum, and have
tried to help the general Linux/MIPS community as
best we can with the limited time that we can dedicate
to the problem, in terms of suggested patches, bug
fixes, cleanups, integration of needed components
like the FPU emulator, etc.
I have to say that the answers I've gotten on MIPS issues on this list
has been exceptionally good, both from the MIPS team and the various other
I have a question for those of you who are doing
Linux work for *new* platforms (as opposed to the
SGI/DEC legacy box support people). IF, and I
emphasize the word *if*, MIPS Technologies were
make a bigger investment in MIPS/Linux technology,
be it kernel enhancements, cross/native tools,
userland ports, libraries, or whatever, what would
be your prioritized "wish list"?
Just some unsorted random ideas:
1. Would it be possible to lump some of the different MIPS variants together
more closely? In my dream world I could build one kernel that would boot on
every mips architecture. This way the work can be more general. As it stands
now, if you want Tx39 or Vr41 variants you're working out of a different tree.
With the number of SoC core products coming out at present, this predicament is
only likely to get more serious. I know at one point in time you could boot a
single ARM kernel on several different systems and it would adapt it's
processor specifics at runtime. Such a design might help to bring the MIPS
world together a bit.
2. Tools are always an issue, but as long as new cores keep coming along that have exceptions and additions to the ISA(s), it's going to be good business for gcc engineers...
3. Using glibc in a cross development environment is slightly painful at this
time for all architectures. MIPS is no different. Some general work on glibc
would be good for the whole world. There has also been some work on other
libraries (newlib and uClibc) for especially constrained environments. No
MIPS/Linux support is available for either.
4. uClinux support for the systems without MMUs. There is considerable interest
in this effort, but I think many people underestimate the magnitude of effort
that will be required to have a truly solid port. This effort might be daunting
for any one vendor, but could benefit all.
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9257
fax : (256)-837-3839