Story of OK labs (1): starting from scratch

Http://microkerneldude.wordpress.com/2014/08/29/ok-labs-story-1-the-beginning/:

Note: Supplement to sel4 background

Last week, I promised to talk about the history of the open kernel lab. This is the first part.

It all started more than a decade ago. One morning I received a call from Kevin and he said he was an intellectual property lawyer at Qualcomm. When you know their nature, it will usually make your spine cooler. However, the conversation is very friendly. He wants to know details about the IP status of our L4 microkernel. Our L4 microkernel is embedded pistachio, there is an open-source BSD-based license (the release of June '08 still exists ). This is from the pistachio kernel fork of karsrueu, which we migrated to a variety of architectures earlier, including arm. This branch is especially used to optimize embedded system applications with limited resources.

After receiving a call, I walked into the lab and told my students that Harvey immediately came up with a guy named Eric using the Yahoo address, you have asked a very detailed technical question on the email list.

In May 2004, Qualcomm was very interested in our kernel. After a few weeks, I went to the United States. In early June, I visited them in San Diego with a confidentiality agreement (which expired a long time ago ). It took me a few hours to have a heated technical discussion with Vice President and a Senior Engineer (Eric). As a result, I went there again in early August and added my student Benno, provides a three-day L4 Design Course, principles and usage (paid at consulting prices, including business class flights ). The audience was about a dozen of engineers from Qualcomm, and some customers were added.

The course went smoothly. In September, we got a contract to provide consulting services to help Qualcomm engineers develop prototypes. Initially, this work was done by Beno and Karl, but expanded to about 6 full-time employees as time went on. Just half a year later, around February 2005, we had nothing to know about it for a long time. Qualcomm decided to put L4 into production as their modem firmware and the kernel under the brew operating system. The first mobile phone running L4 (Toshiba w47t) began shipping in Japan in the second half of 2006.

We are only aware of the technical reasons behind all these issues over time. It turns out that Qualcomm had two problems at the time. One of them is the design of the plane address space of their modem stack and the highly integrated brew operating system. This has grown to millions of lines of code. debugging such a beast without memory protection is a nightmare. With the spread of applications in that era, is it obvious ?? Become more serious. Obviously, it cannot support an open environment (using any third-party applications. There is also a need to modularize the modem stack.

Qualcomm's a plan is to transform protection into Rex, their own RTOS. Some people predict that this effort will fail and are looking for a Plan B (apparently we are planning B .2 and I have never found out what B .1 is .) Failure must be very compelling, resulting in an astonishing and rapid transformation from evaluation to deployment of L4 (although Eric did some prototype work before they found us ).

The second reason is that Motorola has made a strategic move to use Linux as its mobile operating system. The Linux-based Motorola mobile phone has been shipped in China. They want to use Qualcomm chips on Linux phones. Qualcomm does not want Linux (or any GPL software) anywhere near their core IP addresses. To sell chips to Motorola, they need a way to isolate their IP addresses from Linux. In short, they are looking for a virtualization solution, and we can run earlier Linux versions in our L4 kernel. They are looking for a variety of candidates that meet their requirements and need to meet:

1. Supports virtualized Linux,
2. Has the ability to efficiently run their modem stack, and
3. Run on the ARM processor.

They found that we were the closest to this goal, even though no one (including us !) Claim that we have product-level quality. So they basically agreed with us to achieve this goal, and my students did.

The irony is that the virtualized Linux does not have much impact. Endless delays on the Motorola side are partly due to internal struggles and questions about whether it can provide the required performance (from working groups other than L4 ). Although this type of doubt is unreasonable, it can be understood to some extent. At that time (based on the armv5 architecture), The arm9core had a virtual index and a virtual mark of High-speed cache. This means that the hardware cannot distinguish the data belonging to different address spaces. Therefore, Linux (and other operating systems, such as Windows CE) must clear the Cache during each context switch. Because Linux runs in its own address space in virtualization settings, context switching is required for calling a Linux System Call (another is required for returning a system call ). Even in local Linux, the cache is often cleared, and the performance of Linux is not good. People may reasonably think that virtualization will make this worse.

In fact, it is a reverse: On the arm9-processor, running a virtualized Linux on L4 is faster than the native! This is because of the use of a pretty good hardware function, which enables context switching in L4 to be very fast (up to 50 times !), We have actually published this "FASS" technique, but none of our competitors have picked it up, it seems that it is beyond their capacity (it is not surprising that we have found this fact after a period of competition, but I will talk about it next time ). We have implemented the original FASS in Linux, and we have provided it to the main line, but the maintenance staff refused because it is too complicated. What is 50 times the cost?
A professional Motorola engineer developed on L4 finally obtained a Linux mobile phone market (Motorola evke) based on arm9-and virtualization ). I have used it and it is very useful. It seamlessly integrates Linux-based and brew-based applications. Much more than the painful slow HTC tytn-II, although it has a more powerful arm11 processor running Windows Mobile. But it's too late. By that time, smart phones require higher performance than such low-end processors (even if there is no virtualization or Shared Modem with the processor), so the trend is separated, powerful application processor. In the era of "unified" mobile phones, applications and Real-time Operating Systems (supporting modem stacks) run simultaneously on the same processor.

Story of OK labs (1): starting from scratch