Frequently Asked Questions

General

Q. What does "Prex" stand for?

Portable realtime embedded posix OS.

Q. What license are you using for Prex?

Prex is released under BSD license. We know some manufacturers of 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. Currently, some documents are available to learn Prex.

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...

Q. Who is running in the Prex logo?

His name is Preky. This "clock head" runner is always running to keep on time. It represents the Prex characteristics about "non stop", "on time" and "high response". You can see more about him at this page.

Features

Q. What hardware platforms does it support?

Current version supports i386 & ARM platforms. Although there are not so many embedded systems with i386-pc, it is our primary target platform. This is because i386-pc is used widely, and so peoples can test Prex easily. We have plan to port it to MIPS, PowerPC, 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 will be 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. Is the kernel configurable?

No. The kernel options are intentionally kept few 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.

Development

Q. What is required to build Prex?

GCC, GNU binutils and GNU Make. ~~Since the source codes depend on GCC extension, it is difficult to use another compiler to build Prex.~~
(Update: Almost code are written in ANSI-C code now.)

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?

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 is interested in this project. Please feel free to post your patch to the developer mailing list. Of course, we welcome even if you post only your idea without code.

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.

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:

To minimize the interrupt latency.
To keep the total memory size small.
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 reason why demand-paging feature was dropped from Prex kernel.