| Adeos -- a resource sharing multi-OS environment |
Rick Lehrbaum (Feb. 20, 2001)
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 karym@opersys.com.
Related stories: Talk back! Do you have a question or comment on this article? talkback here
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Linux is a registered trademark of Linus Torvalds. All other marks are the property of their respective owners.
news feed