About Us | Contact Us
Navigation

Frequently Asked Questions

Table of Contents

General

Features

Development

Technical


General

Q. What does "Prex" mean?

The original name was Precs (Portable realtime embedded computing system).
The spelling was later changed to Prex.

Q. Where can I get Prex?

The current version can be obtained at http://sourceforge.net/projects/prex/.

Q. What license is used for Prex?

Prex is released under 3-clause BSD license. We know some manufacturers for commercial products are considering about GPL because they sometimes don't want to publish their modified code. And, we also think they should be free to do with their code as they wish. This is the reason why we use BSD license.

Q. Can I use it for a commercial product?

Yes. Please follow the Prex license term. This license allows you to use the source code free of change in your commercial products. You don't have to tell us about your products. But, we are happy if you inform us of the usage of Prex.

Q. Can I use it in OS education class?

Yes, of course. The simple and small codes of Prex kernel will be a good starting point to learn about OS kernel. In practice, Linux or BSD variants are too complicated to be hacked by kernel beginners.

Q. Why don't you use real-time or embedded Linux?

Some companies release the kernel patches to improve the real-time performance of Linux. But, Prex is fully optimized for embedded and real-time systems by default. It is nonsense to use the desktop/server OS on embedded platforms, or to maintain many patches for different kernel versions.

Q. Which OS is an ancestor of it?

Prex's Not UNIX. Since Prex kernel was written from scratch, there is no ancestor of it. But, regarding its design, it was inspired by a lot of OSes: Linux, BSDs, Mach, Amoeba, Minix, Hurd, L4, Chorus, VSTa, QNX, Solaris, WinNT, WinCE, iTRON, eCos, etc. Thanks to these great predecessors...
Back to top ↑

Features

Q. What hardware platforms does it support?

Current version supports x86, ARM & PowerPC platforms. Although there are not so many embedded systems with x86-pc, it is our primary target platform. This is because x86-pc is used widely, and so peoples can test Prex easily. We have plan to port it to MIPS, and Hitachi-SH platforms in future. You can check the current development status at this page.

Q. Does it support multi-processor systems?

No. Currently, Prex is designed only for uni-processor systems because of its performance and simplicity. OK, we know recent processor trend is moving to multi-core. This is one of our discussion item.

Q. Does it support MMU-less system?

Yes. It is designed for both of MMU and MMU-less system. If the processor does not have MMU, the memory protection is not provided. In that case, any application bug can stop the entire system. There is no difference about the kernel API between MMU and NOMMU system.

Q. Which is it hard or soft real-time?

As of now, Prex is a soft real-time system. It does not guarantee to keep a deadline, although hard real-time systems must always respond in time. However, we may support some deterministic real-time scheduler like EDF (Earliest Deadline First) or RMA (Rate Monotonic Analysis) in future.

Q. What file system does it support?

The Prex primary file system is ramfs. And, fatfs or some other file systems are also supported for removable storages. Because the power supply may be unexpectedly cut off with an embedded system, the Prex file system is designed in consideration of this point.

Q. Which POSIX features are supported?

Prex supports standard UNIX APIs and standard C library (libc). Although the code in libc is derived from BSD, it is customized for memory constrained systems. You can check the current status of POSIX compliance at this page.

Q. Does it support a command line shell?

Yes. It is included in CmdBox. CmdBox is a small application which includes tiny versions of many UNIX utilities. You can check the available commands in CmdBox User's Guide.
Back to top ↑

Development

Q. What is required to build Prex?

gcc, GNU binutils and GNU Make. Or, PCC (Portable C Compiler) can be used instead of gcc. Since almost all codes are written in ANSI-C code, it's easy to use another compiler to build Prex.

Q. Do you have a plan to port it to IBM S/390?

No. It is not good idea because the Prex's target requisition is completely different from the mainframe's one. Prex focuses on mobile and embedded systems, and such kind of scalability is not a priority matter of this project. Obviously, it's better to use Linux for S/390, isn't it? :-)

Q. Will you develop GUI, Web Browser or Office Software?

No. It is beyond of the scope of this project. We will port the existing open source software for them, and this is the reason why we support POSIX emulation. I don't have enough time to make entire system from scratch!
"Ars longa, vita brevis." (Art is long, life is short) -- Seneca

Q. How can I contribute code?

Please send your patch to the developer mailing list. Since this is an open source project, you can freely change the code and try any new idea. I am going to be open to all people who are interested in this project. Please feel free to post the patch, and of course, we welcome even if you post only your idea without code.

Q. How do I post a patch?

First read this entire FAQ, then create a patch using diff and post it to the developer mailing list. Please make sure that your patch meets the Prex coding standard.

Q. Can I apply GPL'd code to Prex?

No. It is because the software including GPL'd code must be released under the GPL license. Please ensure that GPL'd code is not included in your patch, before sending it to us.
Back to top ↑

Technical

Q. Is it a preemptive kernel?

Yes. Prex kernel is fully preemptive. This means that, when a higher priority task becomes ready to run, the kernel preempts the current task immediately even in kernel code. It is very important to get the better real-time performance.

Q. Why does the device driver run in kernel mode?

In general, the modern microkernel runs device drivers in user mode. But, Prex device drivers work in kernel mode because:
  1. To minimize the interrupt latency.
  2. To keep the total memory size small.
  3. To simplify the communication between drivers and kernel.
In order to get debugging facility, the Prex driver module is separated from the kernel module.

Q. Does it support memory locking?

Memory is always locked with Prex. Since all pages always exist, the real-time task doesn't have to wait the page loading. This is one of the reasons why demand-paging feature was dropped from Prex kernel.

Q. Is the kernel configurable?

No. The kernel options are intentionally limited to few options in order to provide the single and common kernel service on any different platforms. This helps to keep source codes clean and prevent a #ifdef nightmare. However, BSP (device drivers) can have various options to support many different H/W configurations.
Back to top ↑