On a regular basis, Gna! people will pick and interview one vivid and mature project to highlight the software and personality that drive Libre Software community, similarly to SF.net project of the month -- yes, we assume the fact that we grab good ideas from others places.
The first hotspot is dedicated to the Adeos project. Adeos Description: -------------------------- 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. Adeos was registered on Gna! on February 2004 and is leaded by Philippe Gerum and Karim Yaghmour. An Interview with Philippe Gerum: ------------------------------------------------- | Gna!: Hello, | Can you give a two line description of Adeos your grandma(s) could | understand? What is the intended audience of Adeos? Philippe: Let's say that you want to write your own kernel aimed at delivering very specific services, but you don't want to take the burden of implementing the set of common tasks needed to build a full-fledged O/S, because: 1) it would divert you from your main goal, which is focusing on a specific technical area; 2) other kernel hackers would likely be much more up to this task than you are. This problem can be solved by hosting your kernel on the same hardware than an existing kernel like Linux, which will happily manage the tedious work for you, such as the boot process, the storage management and so on. To this end, you have to find a mean to efficiently share a few critical hardware resources, so that both kernels can run in parallel on the same box, and provide the kind of services they are best suited for to their respective applications. Adeos is such a sharing layer. A direct application of Adeos is having a real-time system run in parallel of Linux on the same hardware. Because real-time applications are more prioritary than regular Linux ones with respect to hardware interrupt handling, the real-time machinery must always be given a chance to process any incoming interrupt before the Linux kernel, so that the real-time processing can take place as soon as possible. Real-time is all about being deterministic when processing events, and Adeos provides a convenient layer to RTOS for implementing this. In that sense, Adeos is a real-time system enabler. | Gna!: Who are you? How many developers contribute to Adeos regularly? | How the project is leaded? Philippe: I'm 39, working as a consultant for Openwide, a FOSS service & support company. I have written most of the Adeos codebase, at the notable exception of the PPC port for the 2.4 kernel which has been fully contributed by Wolfgang Grandegger. A few other people provided us with specific bug fixes and feedback. | Gna!: When was started the project and why? Philippe: This project had two distinct phases. The first one dates back in 2000, when Karim published a paper called "Adaptive Domain Environment for Operating Systems", which described a simple and smart scheme for sharing common hardware resources between multiple kernels running on the same box. He then chose to illustrate the basic mechanism for sharing interrupts on a x86 hardware by mean of a "pipeline" abstraction, feeding each and every kernel in sequence with incoming interrupts according to their given priority in the whole system. Therefore, this paper was already calling for a new way of prioritizing hardware interrupts so that real-time extensions based on the Linux kernel could be developed without making use of the patented process some proprietary RTOS vendor had been granted at that time. Two years later, as I was developing a Linux-based GPL real-time extension called Xenomai, the FUD surrounding the scope of this software patent had become so intense that any attempt to contribute a piece of GPLed real-time code unimpeded by such patent seemed impossible at that time. That's the very problem with software patents: they are granted to people who think they first "invented" what they have just eventually "understood", therefore those people must be either cynical to the bone or totally clueless, which should be enough to make you nervous in either case. In response to such predatory threat, I decided to implement Karim's Adeos proposal, so that my GPL contribution with Xenomai could make use of it and would eventually not be impeded by proprietary considerations. As a result of this, the first Adeos patch against Linux 2.4.18 has been released on June 6, 2002. | Gna!: How things have gone for the project since then? | What are your plans? How do you see the future of Adeos? Philippe: A few months after its initial release, Adeos has been adopted by the RTAI project, the famous real-time extension to Linux; as you can imagine, this move gave a significant boost to the Adeos development. Obviously, having a large user base to test your software shortens the time it needs to reach maturity. Since then, the basic scheme for pipelining interrupts to the clients kernels in a prioritized manner has constantly been improved, and also extended to other resources such as traps, faults and any kernel-originated events of interest. Since day one, the idea was to provide an architecture-agnostic layer onto which one could run an independent kernel in parallel of Linux, by virtualizing key resources in a seamless way. Aside of x86, Adeos has been ported to ia64, arm with and without MMU and PPC. We also ported Adeos over the 2.6 kernel, which is currently our main development focus. As a real-time system enabler, Adeos currently provides the core services needed to run a RTOS along with Linux on the same hardware. Most importantly, Adeos evolution is currently fueled by the work on the next RTAI technology dubbed "fusion"; with this approach, we want to integrate vanilla Linux and its RTAI extension up to the symbiotic level, providing stringent real-time guarantees to regular Linux tasks. Future directions include porting it to other CPU architectures, and also working on a better componentization of its codebase. To this end, I'd like to make the basic interrupt pipelining core emerge as a standalone component, for use by people who are only interested in primitive interrupt handling services. | Gna!: Which license did you choose for Adeos and why? Philippe: It's GPL because it's a piece of Free Software. Additionaly, It's GPL because the Adeos implementation knows and uses the Linux kernel internals to operate, so it conforms to the kernel license. | Gna!: Can you mention some real world use cases of Adeos? Philippe: For the visible part of the iceberg, the most prominent user of Adeos is the RTAI project, which makes use of its pipelining technique to implement a full-fledged RTOS in a GNU/Linux environment. RTAI has a lot of users worldwide including in the industry, and a significant portion of the RTAI install base now runs over Adeos. Philippe: The HYADES project which depends on the ITEA program (Information Technology for European Advancement) has also contributed an Itanium port of Adeos. This incarnation of the nanokernel currently enables their real-time system on large Linux/ia64-based SMP machines. There is also the invisible part of the iceberg, I mean the various individuals and companies who use Adeos for implementing real-time applications, with not much noise in the news, and you just happen to know of them coincidentally. This is quite a good sign too: they don't make a fuss of it just because it works, period. And that's fine. | Gna!: Do you have any industrial or institutional support? | If any, how so? Philippe: As a member of the HYADES project consortium we have just talked about, the Thales Group has funded the ia64 port, and recently, Denx Software Engineering has kindly provided us with test platforms for the PPC port. However, there is currently no sustained industrial or institutional sponsorship for the Adeos project. | Gna!: Are you looking for contributions? | If so, what kind of contributions could be of use to the project? Philippe: I guess that each and every Free Software project is looking for motivated contributors. First of all, we'd like Adeos to be ported over more architectures. We have very limited hardware at hand, so we mainly rely on opportunities like people giving us access to specific hardware, or contributing architecture ports themselves. Next, we'd like that people who have core software development skills work on optimizing the interrupt pipeline as much as possible, especially for non-x86 archs with low memory bandwidth. I'm convinced that the latter issue is going to be very important in the future. | Gna!: What tools do you use when working on Adeos? Why? Philippe: As far as I'm concerned, my preferred tool is my brain; incidentally, this might explain why we issued more than 200 patches to fix bugs or limitations in previous releases for the last two years :o) I'd personally like to be able to use any existing debugger for working on Adeos, but this has not been an option when it would have been the most useful: when bugs are lying somewhere into the interrupt path, the debugger usually goes out of the window with the box when things are getting fishy. Now that the codebase is stable, I'm rather solving arch-specific interrupt latency issues using ad hoc instrumentation, because a debugger would be useless, or at the very least too intrusive when you are dealing with handfuls of microseconds. As you can see, there is nothing particularly spectacular in my toolset. | Gna!: Why did you choose Gna! as host? Philippe: We switched to Gna! after the Savannah debacle in late 2003. It's not the compromise that motivated such move, but rather how it has been dealt with. So we moved for a cosy and reliable environment, and we are pretty happy with such decision. | Gna!: Anything else? Philippe: Yes. Have fun. Links: -------- Home of Adeos: http://www.gna.org/projects/adeos/ RTAI site on Gna!: http://www.gna.org/projects/rtai/ The Adeos mailing list (low traffic): https://mail.gna.org/listinfo/adeos-main Openwide: http://www.openwide.fr/ Home of the HYADES project: http://www.hyades-itea.org/ _______________________________________________ Message sent via/by Gna! http://gna.org/
