Hi, I don't want to vote on any projects in your organization but wanted to speak in generality about the Parrot on RTEMS proposals and what they mean to Parrot and RTEMS as projects. I didn't want to post this as a comment on a proposal because it is more at a management level view of the concept than the value of a particular proposal.
The comments indicated that not being familiar with the issues you face in embedded systems, so I wanted to provide a high level view. RTEMS Background ================ RTEMS is a single process POSIX based embedded real-time operating system that aims for conformance with POSIX Profile 51 or 52[1] depending on the user's configuration. We have ~85% of the POSIX 1003.1b API supported. Currently, we do not have mmap(), shm*(), asynchronous IO, or fork/exec. We do not have virtual memory. What Parrot Brings to RTEMS =========================== + Obviously, the Parrot VM on RTEMS. This has value for all the reasons Parrot has value. + In general, any time something is ported to RTEMS, we find something to tweak. Say a method is missing or we misread the standard and need to fix the implementation of a method. I don't have any specific expectations of what Parrot will find. + Autoconf'ed packages generally build easily to target RTEMS. So we don't expect to find any general infrastructure issues on building Parrot that require RTEMS changes. What RTEMS Brings to Parrot =========================== + Parrot cross building. This is a known issue. + Testing on multiple architectures. RTEMS runs on about 12 processor architectures and we have support for using a FOSS simulator on most of those. This means that once Parrot/RTEMS supports one target architecture, it can be easily tested on others by anyone in your community. Cross architecture testing usually shows assumptions in the code you won't find otherwise. + A target where memory matters. RTEMS is not a virtual memory environment. Most target boards have < 1MB RAM. Some have significantly less. A common configuration is running code from Flash memory that is 10x larger than the amount of RAM available. Others run code from RAM and there can be anywhere from < 1MB to 1GB RAM. + Can't call exit() indiscriminately. Since an RTEMS application is a single process, calling exit() shuts down the entire system and reboots or halts the hardware. + Assumptions about OS implementation. POSIX leaves a fairly wide area for implementations to vary and be compliant. I don't know if Parrot accidentally depends on one of these but if it does, it will turn up. + Code coverage analysis ([2], [3]). We do code coverage analysis at the instruction and branch taken/not taken level using FOSS CPU simulators. We currently can do this on about 5-6 architectures. This infrastructure could be used to ensure your Parrot test suites cover the entire implementation at a very fine level of detail. Conclusion ========== I think there is more work to do on the Parrot side to properly support cross builds to any embedded RTOS than there is on the RTEMS side to support running Parrot. Chris Johns hacked together a port last year which showed a couple of tests running and highlighted the challenges. The decision on what to slot is yours but I wanted to attempt to let you know what I think this project offers to both organizations. References ========== [1] http://www.embedded.com/2001/0104/0104feat4table2.htm [2] http://www.rtems.com/wiki/index.php/RTEMS_Coverage_Analysis [3] http://www.rtems.org/ftp/pub/rtems/people/joel/coverage/ -- Joel Sherrill, Ph.D. Director of Research& Development [email protected] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
