News Archive (1999-2012) | 2013-current at LinuxGizmos | Current Tech News Portal |    About   

Executive Interview: Michel Gien and Michel Genard of Jaluna — Part II

Jan 22, 1997 — by LinuxDevices Staff — from the LinuxDevices Archive — 2 views

Part II — about Jaluna's technology

Q5. How does OSware compare with other dual-OS, telecom-oriented stuff, such as products from Enea or Wind River?

A5, Michel Gien — The other approaches are doing API compatibility layers on top of each other. There are real-time OSes that bring Linux compatibility APIs, like LynxOS. Even QNX has some migration path for migrating from Linux to QNX. Wind River is building a VxWorks API emulation on top of Linux.

What we do is not stacked, but side by side. In the case of VxWorks, it's running VxWorks with the VxWorks API, alongside Linux and the Linux API. This builds a hybrid OS solution in which the two OSes run almost in native mode, with their own drivers, their own performance characteristics. So they're really side by side, instead of one being on top of the other one.

Q. And yet, applications on either OS can communicate through IPC (inter processor communications)?

A6, Michel Gien — OSware provides low-level communication between the two OS kernels. We provide this at the level that is seen from each OS as a bus driver. So, typically, an OS kernel that has a driver for a PCI bus would communicate with the other OS using this PCI bus API that we provide through software in the OSware layer. Then on top of this bus API, you can stack up whatever virtual devices you want. In particular, we can stack up virtual Ethernet drivers; then on top of that, stack up the complete IP stack; and then, in this way, we provide a kind of virtual IP network within the equipment. Or, we can stack other types of communication APIs, like message passing, serial line, or whatever is convenient for the type of applications that want to communicate.


Jaluna system architecture

For example, on [smartphones], very often you have an architecture with an application CPU and a modem CPU. An application on the application CPU would communicate with the modem using serial line and AT commands. We reproduce this on top of OSware, so the applications don't see any difference when both systems run on the same CPU.

Q8. So OSware is really a hardware abstraction layer?

A8, Michel Gien — Exactly.

A8, Michel Genard — An analogy is a hybrid gas/electric car, which runs two engines side-by-side. Obviously, the engines should share some of the drivers, some of the interface — you don't want to have two sets of wheels, or two transmissions. So we partition the resources, the hardware, so you can have multiple operating systems and their applications. We have to virtualize some of the I/O so that the OSes can share the resources.

Q9. With VMware, you essentially need twice as much memory, to run the two OSes. Is that also true of Jaluna OS?

A9, Michel Gien — VMware is a good analogy. People sometimes refer to what we do as the “VMware for embedded systems.” From the functionality point of view, at a high level, you can view it as providing the same kind of solution. Internally, the design is very different. We don't want to provide complete abstraction of hardware, because the overhead in terms of the memory, performance, and in particular determinism — if one of the OSes is a real-time system — would be lost.

VMware provides a full virtualization layer. What OSware provides is a partitioning of the hardware. Some resources are dedicated to one OS instance, which handles and owns the resource, and provides it as a virtual resource for the other OSes. The OS becomes the master for handling this resource, so it has no performance impact on how this OS manages the resource. The other one becomes a client of that OS server. In terms of devices, that's how we split devices between the different OSes.

And then for the resources that are basic to the platform, like the core CPU, the interrupt controller, and some of the MMU stuff, OSware provides the virtualization and scheduling between the different OSes. So this way we kind of separate the different concerns and provide the best performance-rated solutions to the whole system.

In terms of memory, the physical memory is split by OSware between the different OS instances, so there are no interactions between the two, and we can reboot one OS without affecting the other one, for example. The communication bus I was talking about earlier [resides in] physical memory that is handled directly by OSware.

So in terms of memory, we need the memory to run each OS, of course — we don't perform a miracle there. We split the physical memory. We don't provide a virtual memory layer that would add a lot of overhead. But OSware itself is very small, and takes something like 100KB, so it's quite small in terms of memory overhead.

A9, Michel Genard — Another big difference is that one of the purposes of VMware is to provide binary compatibility on the application level, so that an application developed for Windows will run through VMware on the Linux platform. That's not the case with Jaluna OSware. Any application that's running on Linux will continue to run on Linux, and any application running another OS will run on the other OS.

Q10. What real-time OSes does OSware support?

A10, Michel Gien — We have a couple of projects where we support legacy real-time operating systems [developed by] customers themselves. A lot of real-time systems are homegrown, particularly in the telecom area. In terms of more commercial OSes, we've done Chorus, of course, as well as VxWorks, and Nucleus.

We are in discussions with others. It's mainly customer driven. The customer says well, I have this RTOS, and I want to leverage my applications in moving to Linux, and then we talk to the OS vendor and set up a partnership.

Q11. How does your approach compare with those of the open source Xen and Adeos projects?

A11, Michel Gien — Maybe our approach is in between that of Adeos and Xen. First, we have much wider platform support. We support all kinds of CPUs. Xen is focused on x86. We support x86, ARM9, PPC, TI DSP, and we have MIPS on the way, with MMU or without MMU. Also, we are very much OS agnostic, compared with Adeos, as I believe the project is going. We support all kinds of real-time OSes and Linux, but our architecture is not at all limited to Linux.

In terms of Xen, the main difference is that because we focus on embedded systems, we provide support for real-time OSes with determinism, keeping the determinism of the real-time OS as well as supporting Linux. Xen is really focused on providing multiple Linux systems.

In terms of the Linux modifications or adaptations we need to support the Jaluna approach — we are developing some Xen compatibility APIs so that we will support Xenolinux on top of OSware, for example.

So, we do follow these developments, but we position ourselves, first of all, as a commercial, supported, industrially validated product. We believe it's very important for the customers to have a system that's supported. And the second aspect is that we are really focused on developing for the embedded market, as opposed to only focusing on x86 and enterprise systems.

Michel Genard — I'd like to add something to focus in on the key differentiator between us and all the other solutions. We are not touching anything at the BSP, driver, or application level.

In other words, let's say the customer already has his application running on a real-time operating system, and wants to evaluate, or migrate, or bring Linux to the device. Jaluna OSware allows them to bring the application untouched — no API, no modification, no nothing. And, it can reuse the driver, the driver that has been working for the real-time operating system. So OSware can bring Linux, and all its applications and drivers, and get them running in our virtualization and partitioning system.

That's a big difference from other systems, which require either some modification to the application, at the driver level, or a little bit of both, or significant patches at the kernel level. That's not what we are focusing on. That's the value that our early adopters have been giving us as feedback — that we accelerate the migration and integration of operating environments on the same device.

Michel Gien — With the Xen approach, drivers are more or less part of the virtualization layers. In our case, only the drivers of the shared resources are part of it.

That's actually one of the big advantages. People are mostly interested in Linux, in the embedded spaces we've seen, because it comes with drivers, like USB drivers, bluetooth drivers, stuff like that that's complicated to develop for a particular real-time system. And so, our customers would run the real-time application they have already on their RTOS, and then bring Linux to support the USB or bluetooth stacks. Or Internet stacks.

Michel Genard — Another advantage to the Jaluna architecture is at the tools level. The developer can use any native environment that comes with the operating system. If you are using Nucleus, you are going to use all the Nucleus native tools. If you are using VxWorks, you're going to use Tornado or Workbench. If you are using Linux, you are going to use your GNU tools, your GCC, or your DevRocket development tools. We are not imposing another studio development tool.

Q12. Is OSware distributed as binary or source, and do customers ever modify it or do development work on it?

A12, Michel Gien — OSware is distributed as binary. We are licensing the source code to some very specific customers.

Q13. Thinking of it as embedded VMware… If you're using unmodified device drivers, how do you deal with the requirements of a hard real-time system, when the device drivers for Linux might not be interruptible?

A13, Michel Gien — OSware handles interrupt control. It provides some priority levels of scheduling within the different OSes. The real-time OS has priority over Linux from the OSware point of view. If there is an interrupt coming from a device that is intended to be handled by the real-time OS, and the current processing is handled by Linux, then OSware will interrupt that and provide the control to the RTOS. The overhead, then, for the RTOS, is a little bit bigger than if the interrupt comes in when the processing is within the RTOS system, but we bound the maximum time that the RTOS will wait for the interrupts when the control is handled by Linux.

Q14: So, you must be giving control of the interrupt controller up from Linux?

A14, Michel Gien — Yes, that's part of the adaptations we have to do to a Linux system when it runs on top of OSware.

Q15: And you're able to successfully do that without violating the RTLinux patent?

A15, Michel Gien — Yes, we use a different approach than RTLinux. When we are talking of virtualization, the interrupt device is an example of what we virtualize. It's OSware that controls the interrupt controller, not Linux, not the other RTOSes. OSware itself is providing the abstraction layer, and whatever OS runs on top, it's OSware that controls it.

Q16: You said you're not modifying the operating system, but it seems like you must be patching it?

A16, Michel Gien — Yes, we are… it's like a port, if you like. We take the implementation of the kernel for a given processor, and then we do adaptations of the initialization code, of the interrupt handling code, of the lower-level board support code within the OS.

If you look at Linux, for example, the Linux port of OSware is an additional leaf in the source tree for the Linux distribution for that particular CPU architecture. It's an extension of the CPU-specific code to have CPU-plus-OSware support.

Q17: So you're basically doing an OSware BSP, for each OS that you port?

A17, Michel Genard — Yes, but the applications and drivers are key. When a customer has a problem, such as how to migrate to Linux, as an example, they are always challenged with legacy applications. The biggest challenges are at the driver level, because they spend a lot of time optimizing a driver for their operating system, and at the application level, not so much because of the porting effort, but because of the testing and validation or certification (for example with wireless protocols GSM, GPRS, or a GPI stack). So it's a big win to have a solution that allows migration without touching the application. It's easier to have the patches, or BSP, for OSware, than anything else.

What slows down [Linux] adoption in some markets is not the business model that much, and it's not the technology. It's purely how you go from A to B, and whether you can afford the total cost of moving from A to B in a smooth way.

Q18: Can you tell us about the EAL5 Linux project that Jaluna is working on with Mandrake and a few others. What is Jaluna's role in that project?

A18, Michel Gien — Jaluna is the system partner on this project. We'll deliver a trusted version of OSware that will be certified at the EAL5 level, and that will be able to support on one side, multi-level security Linux systems, and on the other side, the secure APIs that will be able to support security agents, or third-party trusted software.

Q19: So it will be a way of getting Linux running under an OS that is EAL5 certified, rather than an EAL5 version of Linux per se?

A20, Michel Gien — Exactly. The end solution will allow users to build secure Linux-based solutions out of possibly insecure Linux implementations. From an architectural point of view, it's based on the fact that you really cannot have a door that is open and closed at the same time. The open door is the ability of people to bring in applications. The purpose of Linux is to be an open system. The closed part is the part that needs to be trusted and controlled, that the system manager or system designer will handle.

Q21: How does OSware compare with what OnCore was doing back in 2000?

A21, Michel Gien — OnCore stacked OS instances on top of a microkernel. It was more similar to what we were doing with Chorus. OSware is not an OS. It's a resource that sits between the hardware and the OS instances.

Another difference is that we provide components within OSware that allow users to tune and configure systems from [the standpoint of] performance versus security isolation. If we have a system that is prone to attacks, we want a high degree of isolation between the various OS instances. On the other side, when you run applications you know can be trusted, you can remove some of the high isolation and security barriers, which benefits performance.

Michel Genard — One of the things that was challenging for [OnCore] is that it requests that the customer use a specific API. Every time a company has provided a solution that requests a customer to use a porting kit, or a specific API, or to map the system core from operating system A to B… it's very difficult to succeed, because the value proposition goes away.

Jaluna OSware is not an operating system. It's an infrastructure, it's a resource between the hardware and the different OSes, that will take care of the management of the device. It's not like an operating system with its own API, so there is no migration in that regard.

Q22: But it must have a small real-time kernel built into it?

A22, Michel Genard — There's a small scheduler… in the modern world, an operating system means you have a lot of things. You have a filesystem, a bunch of things. And OSware doesn't really qualify as an operating system.

Q23. In that sense is RTCore, the kernel of RTLinux, somewhat similar? It's a very small kernel that doesn't have a filesystem, and is mainly there to manage priority among tasks and handle the interrupt controller.

A23, Michel Gien — The big difference is that RTCore supports applications, APIs. OSware supports OSes. It does not support applications. It supports OS kernels, with their own scheduling, their own memory management, their own low-level hardware support. So the level of abstraction of OSware is one level down from RTCore, RTAI, or whatever other RT-whatever kernels.

Another analogy is that it's more like a BIOS. It's an OS scheduler, it's not a task scheduler.

Next . . . Part III — Jaluna's perspective on and
predictions for the embedded Linux market

Story Navigation

Read all the interviews in our Executive Interview Series

Other Related Stories

 
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.

Related Posts:



Comments are closed.