Karim Yaghmour, author of the Linux Trace Toolkit, recently launched a new open source project to develop an “Adaptive Domain Environment for Operating Systems” (Adeos). The purpose of Adeos is to provide a flexible environment for sharing hardware resources among multiple operating systems, or among multiple instances of a single OS. According to Yaghmour, Adeos will support the kinds of dual-OS Linux environments that are today achieved using RTLinux or RTAI, but without making use of the technology that is the subject of Victor Yodaiken's RTLinux patent.

Adios architecture
Details on implementing Adeos with an x86 processor and Linux as the host OS are presented in a whitepaper entitled the Adeos Design Document, which is available as a postscript or pdf download from the Adeos website. A second whitepaper discusses building a real-time operating system (RTOS) on top of Adeos.

A more detailed description of Adeos is available here.

LinuxDevices.com's Rick Lehrbaum contacted Yaghmour for further clarification about Adeos and the motivations behind it. Here's what he learned . . .

---

RL: As I understand it, what mainly exists today are a pair of whitepapers about Adeos. Is this correct?

Yaghmour: Yes. The first paper discusses the design and implementation of a nano-kernel-like facility that may be used to take control away from an unmodified running Linux (on an x86) for further uses, including: patch-less kernel debuggers/probers; running multiple general purpose OSes on the same hardware; OS development; etc. The second document discusses a special case usage of Adeos, that enables a real-time kernel to co-exist with Linux on top of Adeos. This is especially important, as the method described is very likely to not be covered by any patented process. The documents can be found on the Adeos website.

Please keep in mind that the documents are only a suggested method of doing things designed to stimulate discussion. There isn't one line of functional code out there (yet).

RL: When did you launch the Adeos proposal and papers?

Yaghmour: The Adeos proposal papers were launched on February 15, 2001.

RL: What license do you plan to release Adeos under?

Yaghmour: There's already some Adeos code here. As the license accompanying the code shows, it will be under the GPL. I see no reason to release it under any other license.

RL: Will the Adeos interrupt pipe technique be patented?

Yaghmour: No is the short answer. Doing so would show a gross misunderstanding as to the ingenuity of the people that make up the open-source / free-software movement and, therefore, the viability and worthiness of open-source / free-software.

RL: How many others in addition to yourself are currently engaged in this project?

Yaghmour: As with many other GPL projects. This project has started with one person, me. That being said, there are many people who have expressed interest in helping in the development of Adeos. As with other projects I have worked on, interest comes with results and results come with interest. This cyclic process can only be fruitful if interest generates results. Hence, I invite more people to read the paper, make suggestions AND contribute code.

RL: Have you thought about moving Adeos to an open source development site?

Yaghmour: Yes. There is now an Adeos area on SourceForge, here. Also, anyone interested to participate in the project or that has pertinent information regarding the implementation, or its feasibility or lack of, as described in the Adeos document, is welcome to contact me directly.

RL: The documents, especially the long one, look well researched and well thought-out. Is there corporate funding behind this effort?

Yaghmour: I haven't heard from any vendor in particular, although such funding would be very welcomed. As with other projects out there, this doesn't have to be a single-vendor thing. I think this issue touches enough parties that a multi-vendor initiative would be feasible. If nothing else, by providing “enlightened” man-power to the project Adeos would yield results faster.

Also, Adeos relies on processor-specific capabilities to achieve its functionality. Given the special usage made of the hardware, it is very difficult to develop Adeos on a bare-bones system since any mistake brings down the whole system and there is no sure way to understand what went wrong. Hence, providing equipment or access to equipment in the form of an In-Circuit Emulator for an x86 processor would be very welcomed. If any vendor has access to such an equipment and wants to commit one of his technical staff to the project, this would be a big boost for Adeos.

RL: I'm not clear about how Adeos gains its priority position in the interrupt passing chain. To make it work with, say, an essentially unmodified Linux kernel (as described in the second paper), wouldn't you have to play the interrupt controller emulation game for which Yodaiken claims a patent? I assume you've got a good answer to that, so could you please spell it out?

Adios' interrupt pipe
Yaghmour: First, there's a question that needs to be asked, which is: Would modifying the Linux code to catch the disable/enable interrupt calls for a __generalized__ use, as embodied by Adeos, violate the patent?

To answer that question, one needs to read the patent. There are 11 claims in the patent, and 6 drawings. First off, the 6 drawings do not match the description or the end embodied by Adeos. Furthermore, there are 2 claim paths in the claims listed. Claims 2, 3, 4, 5, 6 rely on claim 1 to be valid. Claims 8, 9, 10, 11 rely on claim 7 to be valid. Hence, claim 1 and claim 7 are pivotal to the patent. Yet, claim 1 and claim 7 contain the following statement: “providing a general purpose operating system as one of the non-real time tasks”. This doesn't apply to Adeos, as Adeos is not an OS. It is only an adaptation layer to enable multiple OSes to share the same hardware. Even so, a real-time OS running alongside a general purpose OS using Adeos might not even be aware of the general purpose OS's existence and would certainly not participate in its scheduling. Therefore, I would have to answer that, by providing such a generalized mechanism, Adeos is not subject to the effects of the patent.

RL: According to what you've just said, Adeos itself would be not be subject to the patent. What about a real-time OS that uses Adeos to operate in a dual=OS environment along with Linux? Would it be subject to the patent?

Yaghmour: Here again, the answer would be “No”, since the real-time OS wouldn't take control of any general purpose OS interrupt mechanism. It would make its requests to Adeos. Adeos would then take care to insert it in the requested pipeline priority. No need for the real-time OS to schedule anything. Once it is finished with pipeline control, it goes into a dormant state and the interrupts follow their course in the pipeline where the next stage may be a kernel debugger or a driver needing fast response times. Furthermore, a real-time OS running on Adeos should never attempt to disable/enable interrupts by itself. It should use Adeos' pipeline mechanisms, which are to stall/unstall the pipeline stage. Therefore, an RTOS would have no preferential treatment as far as hardware manipulation of interrupts goes.

That being said, many people feel shy about modifying the Linux sources and would rather use a “vanilla” Linux for their work. This is where the processor features of the x86 come in handy. Since Adeos needs to hook onto the main software-flow-controlling hardware, interrupts, it needs to make sure that no domain in the pipeline, other than Adeos itself, controls the pipeline. On the x86, Linux is used to run at ring-zero with the user-applications running at ring-three. This grossly amounts to supervisor-mode/user-mode on other architectures. Hence, Linux can issue hardware-modifying instructions it needs, while user-processes have no such right. Adeos uses these restrictions to its advantage by pushing Linux into ring-one, one privilege less that it is used to be in. Having done so, any cli/sti (disable/enable interrupt, respectively, on the x86) become illegal and will generate a processor fault when used. Nonetheless, Linux can continue managing the memory and attend to devices, but it is no longer able to issue privileged instructions. A clever scheme is used, as described in the main paper, to lead Linux into believing that it is still in control of the hardware.

By itself, I think that Adeos' architecture isn't subject to the patent's applicability. The non-modification of Linux is an extra reason and a feature that will be welcomed by users who would prefer not to modify Linux in any way.

RL: Thanks very much and good luck with this interesting new project.

---

About Karim Yaghmour: Yaghmour is the author and maintainer of the Linux Trace Toolkit. He has contributed to many open-source projects including RTAI and RTNet. He recently started the Adaptive Domain Environment for Operating Systems project which will enable system programmers and system administrators to have greater control over the hardware they manage. He is the founder of Opersys Inc., which provides expertise and courses on the Linux kernel and its real-time derivatives. He can be reached at [email protected].

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.