Hi Kevin, 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 individuals. > 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. -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9257 fax : (256)-837-3839
