Cooperative Linux
1
SEMINAR ON “CO-OPERATIVE LINUX”
Presented by: Pravin G. Nimodiya Amit A. Ohale
Cooperative Linux
2
CERTIFICATE
This is to certify that Mr. Pravin Ganesh Nimodiya Mr. Amit Anilkumar Ohale from COMPUTER SCIENCE AND ENGINEERING has successfully delivered a seminar on “COOPERATIVE LINUX” and has submitted a satisfactory report about it as per syllabus of Shri Guru Gobind Singhji Institute of Engineering & Technology, NANDED during the academic year 2006-07.
Date:
Head of Dept
Lect. Incharge
Cooperative Linux
3
ACKNOWLEDGEMENT We feel great pleasure in submitting this seminar report on “COOPERATIVE LINUX”. We wish to express true sense of gratitude towards my seminar guide, Miss. Puja Borlepawar madam, who at very discrete step in study of this seminar contributed her valuable guidance to solve every problem that arose. We wish to thank our Dr. J. V. Aghav sir for opening the doors of the department towards the realization of the seminar report. We also express our thanks to all friends for their undying support shown during the preparation of this seminar. I owe my all success to them.
Pravin G. Nimodiya Amit A. Ohale
Cooperative Linux
4
Table of Content 1. Abstract
………. 5
2. Introduction
………. 6
3. History
………. 7
4. Uses
………. 8
5. CoLinux first Impression
………. 9
6. Design Overview
………. 11
7. Installation
………. 16
8. Compiling under CoLinux via GCC ………. 27 9. Other Auxiliary tools
………. 29
10. Interaction between Tools
………. 31
11. Current status of CoLinux
………. 33
12. Planned Features
………. 35
13. Disadvantages
………. 37
14. Conclusion
………. 38
15. References
………. 39
Cooperative Linux
5
1 Abstract Software development for an embedded Linux system in most cases requires a free license of GCC (GNU C/C++ compiler) and accessories. Many developers find it disconcerting that the GNU tools are primarily available for Linux-based PCs. Any attempt to make GCC run under Windows in order to program an embedded Linux system has been fraught with problems until now. The popular Cygwin – as a Unix/Linux emulation environment under Windows – is much too slow and in most cases causes significant library and version conflicts. Despite the high costs, commercial attempts by some companies to provide GCC as a Windows application have not lead to any practical solutions. Even here, there are typically significant library problems. As a result, many users have no other alternative than to use a Linux distribution as a second operating system on the Windows PC to be able to use GCC tools. Without some effort, this technically straightforward solution is not feasible for large companies in particular, because an IT department is responsible for the PCs. Users are not able to just install a new operating system to boot instead of Windows. Another obstacle is often times getting familiar with a new PC operating system.Many questions can arise, such as: How can I change the network settings (e.g. IP address, etc.)? Where can I find a Telnet client? Which editor should I use? How can I later install other software components? The list could go on ad nauseam. The bottom line is that significant orientation time is required for a knowledgeable Windows user to get familiar with the new environment.
In this report we’ll describe Cooperative Linux, a port of the Linux kernel that allows it to run as an unprivileged lightweight virtual machine in kernel mode, on top of another OS kernel. It allows Linux to run under any operating system that supports loading drivers, such as Windows or Linux, after minimal porting efforts. The report includes the present and future implementation details, its applications, and its comparison with other Linux virtualization methods. Among the technical details I’ll present the CPU-complete context switch code, hardware
Cooperative Linux
6
interrupt forwarding, the interface between the host OS and Linux, and the management of the VM’s pseudo physical RAM. An alternative to using a Linux PC is a free license of Cooperative Linux (coLinux).This Linux project is a new approach to getting the Linux kernel to run under Windows XP. CoLinux contains special Windows drivers, which allow it to run under Windows XP as a guest operating system with all privileges.
2 Introduction Cooperative Linux utilizes the rather underused concept of a Cooperative Virtual Machine (CVM), in contrast to traditional VM’s that are unprivileged and being under the complete control of the host machine. The term Cooperative is used to describe two entities working in parallel, e.g. coroutines. In that sense the most plain description of Cooperative Linux is turning two operating system kernels into two big coroutines. In that Mode, each kernel has its own complete CPU context and address space, and each kernel decides when to give control back to its partner. However, only one of the two kernels has control on the physical hardware, where the other is provided only with virtual hardware abstraction. From this point on in the report I’ll refer to these two kernels as the host operating system, and the guest Linux VM respectively. The host can be every OS kernel that exports basic primitives that provide the Cooperative Linux portable driver to run in CPL0 mode (ring 0) and allocate memory. The special CPL0 approach in Cooperative Linux makes it significantly different than traditional virtualization solutions such as VMware, plex86, Virtual PC, and other methods such as Xen. All of these approaches work by running the guest OS in a less privileged mode than of the host kernel. This approach allowed for the extensive simplification of Cooperative Linux’s design and its short early beta development cycle which lasted only one month, starting from scratch by modifying the vanilla Linux 2.4.23-pre9 release until reaching to the point where KDE could run. The only downside to the CPL0 approach is stability
Cooperative Linux
7
and security. If it’s unstable, it has the potential to crash the system. However, measures can be taken, such as cleanly shutting it down on the first internal Oops or panic. Another disadvantage is security. Acquiring root user access on a Cooperative Linux machine can potentially lead to root on the host machine if the attacker loads specially crafted kernel module or uses some very elaborated exploit in case which the Cooperative Linux kernel was compiled without module support. Most of the changes in the Cooperative Linux patch are on the i386 tree— the only supported architecture for Cooperative at the time of this writing. The other changes are mostly additions of virtual drivers: cobd (block device), conet (network), and cocon (console). Most of the changes in the i386 tree involve the initialization and setup code. It is a goal of the Cooperative Linux kernel design to remain as close as possible to the standalone i386 kernel, so all changes are localized and minimized as much as possible.
3 History Dan Aloni originally started the development of Cooperative Linux based on similar work with User-mode Linux and LINE. He open sourced the software under the GNU General Public License. Other developers have since contributed various patches and additions to the software.
Cooperative Linux
8
4 Uses Cooperative Linux in its current early state can already provide some of the uses that User Mode Linux provides, such as virtual hosting, kernel development environment, research, and testing of new distributions or buggy software. It also enabled new uses:
• Relatively effortless migration path from Windows. In the process of switching to another OS, there is the choice between Installing another computer, dual booting, or using a virtualization software. The first option costs money, the second is tiresome in terms of operation, But the third can be the most quick and easy method—especially if it’s free. This is where Cooperative Linux comes in. It is already used in workplaces to convert Windows users to Linux.
• Adding Windows machines to Linux clusters. The Cooperative Linux patch is minimal and can be easily combined with others such as the MOSIX or Open-MOSIX patches that add clustering capabilities to the kernel. This work in progress allows to add Windows machines to super-computer clusters, where one illustration could tell about a secretary Workstation computer that runs Cooperative Linux as a screen saver—when the secretary goes home at the end of the day and leaves the computer unattended, the office’s cluster gets more CPU cycles for free.
• Running an otherwise-dual-booted Linux system from the other OS. The Windows port of Cooperative Linux allows it to mount real disk partitions as block devices. Numerous people are using this in order to access, rescue, or just run their Linux system from their ext3 or reiserfs file systems.
• Using Linux as a Windows firewall on the same machine.
Cooperative Linux
9
As a likely competitor to other out-of-the-box Windows firewalls, iptables along with a stripped-down Cooperative Linux system can potentially serve as a network firewall.
• Linux kernel development / debugging / research and study on another operating systems. Digging inside a running Cooperative Linux kernel, you can hardly tell the difference between it and a standalone Linux. All virtual addresses are the Same—Oops reports look familiar and the architecture dependent code works in the same manner excepts some transparent conversions, which are described in the next section in this report.
5 coLinux First Impression The hardware virtualized by coLinux includes a VGA text console (that is displayed in a Windows XP window), network, hard disk drives (as normal files under Windows) and a keyboard. When selecting the virtual hardware, a configuration was consciously selected that is as minimal as possible in order to avoid driver problems in Linux.
Fig 5.1: The coLinux VGA text console in Windows XP window
Cooperative Linux
10
Figure 5.1 shows the interface of coLinux to be implemented on a Debian Linux under Windows XP. Just a simple mouse click on the previously described icon on the Windows XP desktop is needed to start the configuration. And in just a few seconds, a complete Debian Linux is available in a Windows XP window. The username root and password root are used to log in.
Fig 5.2: Windows and coLinux use a common directory
Windows and coLinux use a common directory on the hard disk drive (c:\colinux from the Windows environment – the same directory is accessible under coLinux under the name /windows). Any files in the directory are accessible from both Windows and coLinux (Figure 5.2). However, the common hard disk drive space is managed by Windows exclusively. coLinux does not access the hard disk drive hardware directly. Consequently, there is no need for a separate coLinux partition. A special driver (coFS = coLinux File System) is used by coLinux to access the Windows hard disk drive. It should be noted, however, that the coFS involves an asynchronous file system. Write operations within the common directory under coLinux or Windows are closed from view of the other operating system only after context is next switched (Surrendering control of the CPU to Windows or coLinux). For this reason, no GCC make file should directly access /windows under coLinux, if files are used by the make file that were previously written under Windows.
Cooperative Linux
11
6 Design Overview This section describes the basic methods behind Cooperative Linux, which include complete context switches, handling of hardware interrupts by forwarding, physical address translation and the pseudo physical memory RAM.
6.1
Device Driver The device driver port of Cooperative Linux is used for accessing kernel
mode and using the kernel primitives that are exported by the host OS kernel. Most of the driver is OS independent code that interfaces with the OS dependent primitives that include page allocations, debug printing, and interfacing with user space. When a Cooperative Linux VM is created, the driver loads a kernel image from a vmlinux file that was compiled from the patched kernel with CONFIG_COOPERATIVE. The vmlinux file doesn’t need any cross platform tools in order to be generated, and the same vmlinux file can be used to run a Cooperative Linux VM on several OS uses of the same architecture. The VM is associated with a per-process resource—a file descriptor in Linux, or a device handle in Windows. The purpose of this association makes sense: if the process running the VM ends abnormally in any way, all resources are cleaned up automatically from a call back when the system frees the perprocess resource.
6.2
Pseudo Physical RAM
In Cooperative Linux, we had to work around the Linux MM design assumption that the entire physical RAM is bestowed upon the kernel on startup, and instead, only give Cooperative Linux a fixed set of physical pages, and then only do the translations needed for it to work transparently in that set. All the
Cooperative Linux
12
memory which Cooperative Linux considers as physical is in that allocated set, which we call the Pseudo Physical RAM. The memory is allocated in the host OS using the appropriate kernel function— alloc_pages() in Linux and MmAllocatePagesForMdl() in Windows— so it is not mapped in any address space on the host for not wasting PTEs. The allocated pages are always resident and not freed until the VM is downed. Page tables are created for mapping the allocated pages in the VM’s kernel virtual address space. The VM’s address space resembles the address space of a regular kernel—the normal RAM zone is mapped contiguously at 0xc0000000. The VM address space also has its own special fix maps—the page tables themselves are mapped at 0xfef00000 in order to provide an O(1) ability for translating PPRAM (Pseudo-Physical RAM) addresses to physical addresses when creating PTEs for user space and vmalloc() space. On the other way around, a special physical-to-PPRAM map is allocated and mapped at 0xff000000, to speed up handling of events such as pages faults which require translation of physical addresses to PPRAM address. This bi-directional memory address mapping allows for a negligible overhead in page faults and user space mapping operations.
6.3
Context Switching
The Cooperative Linux VM uses only one host OS process in order to provide a context for itself and its processes. That one process, named colinuxdaemon, can be called a Super Process since it frequently calls the kernel driver to perform a context switch from the host kernel to the guest Linux kernel and back. With the frequent (HZ times a second) host kernel entries, it is able able to completely control the CPU and MMU without affecting anything else in the host OS kernel. On the Intel 386 architecture, a complete context switch requires that the top page directory table pointer register—CR3—is changed. However, it is not
Cooperative Linux
13
possible to easily change both the instruction pointer (EIP) and CR3 in one instruction, so it implies that the code that changes CR3 must be mapped in both contexts for the change to be possible. It’s problematic to map that code at the same virtual address in both contexts due to design limitations—the two contexts can divide the kernel and address space differently, such that one virtual address can contain a kernel mapped page in oneOS and a user mapped page in another. In Cooperative Linux the problem was solved by using an intermediate address space during the switch (referred to as the ‘passage page,’see Figure 6.1). The intermediate address space is defined by a specially created page tables in both the guest and host contexts and maps the same code that is used for the switch (passage code) at both of the virtual addresses that are involved. When a switch occurs, first CR3 is changed to point to the intermediate address space. Then, EIP is relocated to the other mapping of the passage code using a jump. Finally, CR3 is changed to point to the top page tabledirectory of the other OS.
Guest Linux
Intermediate
Host OS
0xFFFFFFFF
0x80000000
Fig 6.1: Address space transition during an OS cooperative kernel switch, using an intermapped page
Cooperative Linux
14
The single MMU page that contains the passage page code, also contains the saved state of one OS while the other is executing. Upon the beginning of a switch, interrupts are turned off, and a current state is saved to the passage page by the passage page code. The state includes all the general purpose registers, the segment registers, the interrupt descriptor table register (IDTR), the global descriptor table (GDTR), the local descriptor register (LTR), the task register (TR), and the state of the FPU / MMX / SSE registers. In the middle of the passage page code, it restores the state of the other OS and interrupts are turned back on. This process is akin to a “normal” process to process context switch. Since control is returned to the host OS on every hardware interrupt (described in the following section), it is the responsibility of the host OS scheduler to give time slices to the Cooperative Linux VM just as if it was a regular process.
6.4
Interrupt Handling and Forwarding
Since a complete MMU context switch also involves the IDTR, Cooperative Linux must set an interrupt vector table in order to handle the hardware interrupts that occur in the system during its running state. However, Cooperative Linux only forwards the invocations of interrupts to the host OS, because the latter needs to know about these interrupts in order to keep functioning and support the coLinux-daemon process itself, regardless to the fact that external hardware interrupts are meaningless to the Cooperative Linux virtual machine. The interrupt vectors for the internal processor exceptions (0x0–0x1f) and the system call vector (0x80) are kept like they are so that Cooperative Linux handles its own page faults and other exceptions, but the other interrupt vectors point to special proxy ISRs (interrupt service routines). When such an ISR is invoked during the Cooperative Linux context by an external hardware interrupt, a context switch is made to the host OS using the passage code. On the other
Cooperative Linux
15
side, the address of the relevant ISR of the host OS is determined by looking at its IDT.An interrupt call stack is forged and a jump occurs to that address. Between the invocation of the ISR in the Linux side and the handling of the interrupt in the host side, the interrupt flag is disabled. The operation adds a tiny latency to interrupt handling in the host OS, but it is quite neglectable. Considering that this interrupt forwarding technique also involves the hardware timer interrupt, the host OS cannot detect that its CR3 was hijacked for a moment and therefore no exceptions in the host side would occur as a result of the context switch. To provide interrupts for the virtual device drivers of the guest Linux, the changes in the arch code include a virtual interrupt controller which receives messages from the host OS on the occasion of a switch and invokes do_IRQ () with a forged struct pt_args. The interrupt numbers are virtual and allocated on a per-device basis.
Cooperative Linux
16
7 Installation If you have something different, than an Intel compatible CPU with either a Windows XP or a Windows 2000 based operating system, coLinux will not work. You should also have the latest service pack installed. The CoLinux system comes as a tar file that contains a basic subset of components. •
The Windows CoLinux driver
•
A linux kernel vmlinux
•
One or more file system images. o
Root file system
o
Swap file
o
Other file systems
•
A configuration file.
•
A program that creates empty files of arbitrary size: mkFile.exe
If you have a virus scanner with on-access scanning, you should make sure that it is disabled or doesn’t touch the directory, where you want to install coLinux. If
you
have
downloaded
the
installer
package
v.95
from
http://blackfin.uclinux.org/projects/bfin-colinux, you must not unzip it in a directory, which has white spaces in its path. On the Windows machine in which CoLinux is being installed create a root folder(e.g. colinux) where the proper files and subdirectories will be located. Now make sure that you have the following files located in these specific directories:
/colinux/coLinux_setup_rc6.exe /colinux/readme.doc /colinux/extra/PuTTY-setup.exe /colinux/extra/Xming-setup.exe /colinux/sources/colinux-0.7.1-hn4.src /colinux/sources/file-utils /colinux/images/tardump.tgz
Cooperative Linux
17
If installing from a CD then you do not have to copy the files to your hard drive as described above. You may simply run the installation from the CD by running the coLinux_setup_rc6.exe. Now
to
start
the
installation
procedure,
double
click
the
coLinux_setup_rc6.exe icon in the colinux directory. You should receive a welcome screen that looks like this:
Now Click on the Next button. You will then be brought to the coLinux Licenses agreement screen.
Cooperative Linux
18
Here you should read the documentation and accept the agreement and then click Next if you wish to continue. You will then be brought to an information screen which provides the following warning: You should know, that this software installs a Windows kernel driver, that loads a Linux kernel to run aside the Windows kernel.
This software can destabilize or crash your system!!
You should therefore not use software or edit data, that is vital for you or your business, while running coLinux. After you have read this click the Next button to continue the installation. You will then be prompted for the directory that you want bfin-colinux installed in (the default is C:\bfin-coLinux). You should select a drive that has at least 3.2 GB of space left, because coLinux doesn’t use a partition, but stores everything inside two files (rootfs.img and
Cooperative Linux
19
homefs.img) on the windows file system. Due to a coLinux problem the path of the coLinux installation must not contain any spaces. After entering this information click the Next button. Next you will be brought to the Ram and block size selection screen.
Here you have to select the size of the actual installation and the amount of RAM, coLinux should use. The coLinux RAM is exclusively used by coLinux and will no longer be available for Windows (only as long as coLinux runs). You should reserve as much as possible, where a minimum should be 128MB. You have to remember, that Windows also needs RAM and it should have at least 128MB left. For example if you have 256MB, you could try to use 128MB (It is possible, that Windows would not allow coLinux to use that much RAM. If that is the case, try 96MB). If you have 512MB then 256MB or 320MB would be a good idea. Also you should remember that if Windows does not have enough RAM for smooth operation then it will slow coLinux down and could destabilize your system. Also you should not run unnecessary Windows software, while working with coLinux. You should also select a bigger swap size than you have selected the RAM size.
Cooperative Linux
20
The coLinux standard installation uses about 750MB space on the rootfs. So you should at least select 1GB for the root file system. If you want to install additional software, you should select it bigger. For the home filesystem, you should select at least select 1.8GB, since you will be installing the uClinux distribution here. The next step is to select an IP address for coLinux and install the tuntap driver
If this is your first coLinux installation, you should check the Install a TAP driver box and select an IP address for the Windows side of the TAP. It should be an address in a not yet routed class C subnet in the address space of 10.xxx.xxx.xxx or 172.16.xxx.xxx or 192.168.xxx.xxx. (An example of a class C network is 10.12.12.xxx). There is also an option for serial support. If you activate it, you should also select the right COM port. You should also know, that the console will block, while using the serial port. So you have to use a xterm or PuTTY, while working with the serial port. Now you may hit the Next button to move on with the installation.
Cooperative Linux
21
In the next step you can select a different start menu folder name. After you have done this hit Next. The final step allows you to select additional tasks to install. If this is your first installation, you should select the PuTTY ssh client and the Xming X-Server to be installed. You can also select the profile for PuTTY and the service if you want.
If you confirm the installation by hitting Next and then Install, the setup starts. You can see how the installer installs some files. After a few seconds a new window opens. This is the coLinux console. This is part of the installation process. You are now seeing a small Linux system that installs the main system. This will take some time. After a few minutes the window closes and the setup continues with the PuTTY and Xming installation. Maybe Windows asks you if you want to install a driver which is not certified by Microsoft. You should answer this with Yes. When the additional software components have been installed, the coLinux setup shows some information and then goes to the login in screen. Now you have successfully installed coLinux.
Cooperative Linux
22
CoLinux Basics The system consists of a set of Windows drivers linux.sys. The colinux-daemon.exe --install-driver command will set up the Windows system.
Use colinux-daemon.exe -–remove-driver to remove the drivers Then a CoLinux executable can be run to start the linux virtual machine. This system requires the folowing: •
A config file
•
A Linux Kernel
•
An initial Ram Disk.
A full system will also need some disk images: •
A root file system image
•
A swap partition
•
One or more additional images.
In this example system the images are compressed and will have to be uncompressed using a “stand alone” CoLinux boot. CoLinux Root Pasword The CoLinux root password is bf533.
Cooperative Linux
CoLinux Configuration kernel=vmlinux # this specifies the kernel to be used mem=120 # this is the system virtual memory initrd=.\initrd.gz # this is the initial ram disk cobd0=.\root.img # specify partition /dev/cobd0 to point to this file cobd1=.\home.img # specify partition /dev/cobd1 to point to this file cobd2=.\swap.img # specify partition /dev/cobd2 to point to this file cofs0=c:\ # specify device /dev/cofs0 to point to the c: drive root=/dev/cobd0 # specify the mounted root file system. # this can be overridden in the example shown. eth0=slirp,"",tcp:333:22/tcp:1000:1000/udp:69:69 # set up an ethernet connection using the windows host. # devices on ports # tcp 333:22 (ssh) # tcp 1000:1000 (webmin) # udp 69:69 (tftp) # are assigned to services running under the CoLinux virtual machine. eth1=tuntap # set up ether1 to work with the tap controller cofs1=. # set up cofs01 to be the current working directory cofs2=d:\ # set up cofs02 to be the CD # You can just add additional cofs entries for other drives or directories. # But you should know, that if you add a directory like cofsxx=j:\somepath you must # not add a trailing backslash. Only if you reference a drive like cofsxx=j:\ then you # have to add a trailing backslash
23
Cooperative Linux
24
This config file has to work with the /etc/fstab on the root file system image. Here is a typical example: #
<mount point> /dev/cobd0 / ext3 defaults 0 proc /proc proc defaults 0 tmpfs /dev/shm tmpfs defaults 0 /dev/cobd2 swap swap defaults 0 /dev/cobd1 /home ext3 defaults 0 cofs00 /windows cofs defaults,noatime 0
0 0 0 0 0 0
# You can simply add your cofs drives with a simple entry like: # cofsxx /mountpint cofs defaults,noatime 0 0 # You can also use additinal options like "noauto", if you want to mount # the fs manually or "user", if you want the filesystem be user mountable.
With just a few of these components CoLinux can be run in a stand alone mode. colinux-daemon.exe @config.txt root=/dev/ram0 In the above example config file the CoLinux working directory can be mounted as follows: mkdir -p /colinux mount -t cofs cofs01 /colinux
Doing this will allow the use of Linux commands to manipulate the installation kit. For example to uncompress images after booting in stand alone mode and mounting the CoLinux image: gunzip /colinux/swap.img.gz gunzip /colinux/home.img.gz gunzip /colinux/root.img.gz
Cooperative Linux
25
CoLinux Disk Images There are two ways to create disk images with CoLinux, one uses a Windows based tool, the other is the “standard” Linux method. The Linux method only runs under a Linux System. There is a mkFile.exe utility that can be used under Windows to build an image. # At a Windows command prompt # example to create a 2G file mkFile -m mysys.img 2000
This file will then have to be populated within CoLinux but the image mysys.img can be mounted within CoLinux if it is defined in the CoLinux config file. # this is the entry in the config.txt file cobd4=.\mysys.img specify partition /dev/cobd4 to point to this file In the CoLinux virtual machine: # first create an ext2 file system on the disk image mke2fs -F /dev/cobd4 #turn this into an ext3 filesystem tune2fs -i 0 -j /dev/cobd4 # then under CoLinux mkdir -p /mymnt mount /dev/cobd4 /mymount The normal Linux way to make a blank disk image is as follows:
dd if=/dev/zero of=mysys.img bs=1k count=2048k
Cooperative Linux
26
Starting a Colinux Session To avoid errors during initialization, the following CoLinux startup order is recommended: 1. Start Xming 2. Start Blackfin-coLinux (Colinux main console) 3. Login = uclinux passwd = bf533 4. Start bfin-uclinux (Putty console) 5. passwd = bf533 start konsole or xterm (in background) from Putty console 6. Launch minicom from the konsole or xterm terminal
To tftp the kernel to the stamp board you must disable the coorporate firewall: Goto
Control Panel -> Administrative Tools -> Component Services -> Services Local -> Sygate Security Agent -> Under Properties, DISABLE firewall & Restart your PC
A crossover cable, hub or switch does work.
Stopping a Colinux Session When you are ready to end your colinux session, in super user mode, type ‘shutdown -h now’ within the main console. Wait until the main console prints ‘Power down’ before closing all linux windows. This shut down procedure will allow Colinux to start up normally the next time without a reboot.
Cooperative Linux
27
The following commands can be used to terminate a CoLinux session (in super user mode): •
halt
•
shutdown -h now
Both of these will Power Down the virtual machine. The CoLinux Console can then be closed using the Quit command.
8 Compiling under coLinux via GCC A coLinux for embedded Linux development typically contains the original GNU tools for compiling C/C++ programs and corresponding libraries. In addition to the native GCC for x86 code, SSV coLinux contains Cross versions M68KELFGCC (M68K code, output format ELF) and ARM-ELF-GCC (code for various ARM architectures in the ELF output format). The native GCC, for example, can be used to program an ADNP/1520 with an embedded gateway Linux. The M68KELF-GCC lends itself to software development for ColdFire DIL/NetPCs under uClinux (DNP/5280, DNP/5282 and PNP/520). The Linux control DIL/NetPC DNP/7520 is supported by the ARM-ELF-GCC. Other Cross GCC versions can be subsequently added to SSV coLinux, as needed.
Cooperative Linux
28
Fig 8.1: Initial steps with the compilers in SSV coLinux
A good first test of the various GNU tools of an SSV coLinux installation is to create and compile a C program in the coLinux window. These steps, for example, can be executed with the following entries:
cat > hello.c #include <stdio.h> #include <stdlib.h> void main (void) { printf (“Hello...\n”); } CTRL-D (ends the input of the C source text) gcc –o hello hello.c
Cooperative Linux
29
This input sequence results in a C source code file called hello.c. The file is then compiled with the native GCC. The resulting program can be directly executed in the coLinux window. Figure8.1 illustrates this example. In this figure, M68K-ELFGCC is then called up to create an executable for a ColdFire DIL/NetPC from hello.c. The uClinux executable hello is then moved to the /windows/root directory. The file can then, for example, be transferred with TFTP to the DNP/5280.
9 Other Auxiliary Tools There are other tools on the coLinux Cross Tools CD-ROM. The opens source editor PN (Programmers Notepad) is of particular importance. The installation program for this auxiliary tool can be found on the CD-ROM in the Programmers Notepad directory.
Fig 9.1: Editing with the open source editor PN (Programmers Notepad)
PN is capable of editing the C/C++ source code for an embedded Linux module in the familiar Windows XP environment. Resulting source code files can
Cooperative Linux
30
be saved in the common Windows directory c:\colinux. Additional subdirectories (e.g. c:\colinux\root or even c:\colinux\transfer) should be created within c:\colinux for the individual projects, as needed. Another important resource on the SSV coLinux Cross Tools CD-ROM is a TFTP server called TFTPD in the TFTP-Server-Win32 directory. The same server application is also included on the starter kit CD-ROMs for the respective DIL/NetPCs. TFTPD is used for TFTP-based file transfer over an Ethernet LAN connection between PC and embedded Linux module. Figure 8.2 shows TFTPD in use. It should be noted that this programs requires file transfer from a base directory. The Browse button on the TFTP user interface is used to select the directory.
Fig 9.2: The TFTP server is used for file transfer
All TFTP file transfers to and from DIL/NetPCs are based on the TFTPD base directory. Therefore, c:\colinux or a subdirectory within c:\colinux must be selected as the base directory to use TFTPD in conjunction with coLinux.
Cooperative Linux
31
10 The Interaction between Tools The coLinux window itself, the open source editor PN and a TFTP server TFTP can be used together in such a way that the developer will practically never have to leave the familiar Windows XP environment of the development PC. Figure 8 provides an overview of the interaction between the development tools that are used in the coLinux-based development environment for DIL/NetPCs. C/C++ source code is edited in Windows using the PN editor. This Windows application organizes the source code files into projects. All source code is saved in the directory c:\colinux, or a subdirectory within c:\colinux. A script file (build script) is run in the coLinux window to compile the entire project. The script pulls the appropriate source code files from the common directory, activates the GCC sing a make file and after successfully running the GCC writes the executable for the embedded Linux system back to the common directory. The following is an example of such a build script:
#!/bin/sh cp /windows/root/ngsmtp1.c ngsmtp1.c make all mv /tftpboot/ngsmtp1 /windows/root/ngsmtp1 mv ngsmtp1.c ngsmtp1.bak rm ngsmtp1.gdb
The second line of the build script copies C source code with the name ngsmtp1.c from c:\colinux\root (/windows/root in coLinux) to the coLinux directory, in which the build script was launched. The third line activates the GCC make. The GCC make run creates an executable in the coLinux directory /tftpboot. The fourth line moves the executable to the common directory c:\colinux\root (/windows/root in coLinux), from where it can then be transferred
Cooperative Linux
32
per TFTP to the DIL/NetPC. Such a build script is executed from the coLinux window.
Fig 10.1: The interaction between development tools
The user only has to launch the script file in the coLinux window. This essentially eliminates any orientation in Linux as a PC operating system. The Windows TFTP server TFTPD and the standard XP Telnet client in Figure 9.1 are used for file transfer to the embedded Linux system and the shell access.
Cooperative Linux
33
11 Current Status of coLinux
•
Version: 0.6.4
•
Released on date: July 02, 2006
•
Supported architectures: o
Intel-compatible 386 and above
Supported operating systems:
•
Windows 2000
Windows XP
Linux 2.6.x
Supported guest Linux kernel versions: o
2.6.11
Cooperative Linux
34
Here is the list of changes that led to the current version: * Version 0.6.4 * colinux-daemon: Fix incorrect explaination in --help, for --remove-driver. SF Bug#1483449 * Improved building * improvements to cut down on disk size needed to build coLinux * improvements to make process smoother and better handle some errors * Fix do_wp_page: bogus page at address (mainly seen with syslog) when linux is host Thanks to Robert for >=2.6.13 part (2006-02-26) and Bernd Brandstetter for 2.6.12 (2005-10-01). Tested host kernels: 2.6.10, 2.6.11, 2.6.12, 2.6.13, 2.6.14.4, 2.6.15, 2.6.16-rc5 * Fix daemons to read more than one message * Fix for dropped UDP/TCP packets between linux and host daemons. * cofs and cobd: * Allow relative paths in XML (except for \Device & \DosDevices) * Remove trailing backslashes from cofs paths * Improve console output of mapped devices & paths * Case insensitive scans for duplicate paths * cobd: * Fix for reference to NULL-Pointer * cofs: * Fix BSOD for long non-ansi names in directory (Thanks to Kensuke Matsuzaki) * Fix for handling longer basenames (from 127 to 255) * slirp: * Handle larger UDP/TCP packet (more than 3000...4000 bytes of user data * Fix realloc problem that caused slirp to crash (Thanks to Bernd Brandstetter for finding it) * Always set destination address and port, destination port is not always the same (Thanks to Bern Brandstetter for finding & submitting patch) * bind 10.0.2.2 to Window's localhost, instead of window's LAN adapter * Packets from Windows host are translated to 10.0.2.2, other packets are routed but not translated * Slirp redirection now works without any real network adapter * Fix Slirp redirection to work on LAN if colinux started before LAN is connected * pcap/Bridged: * Add promisc="false" in config.xml, or 'nopromisc' as last commandline argument (ie, eth1=pcap,"Local Area Connection","",nopromisc ). Default is Promiscuous on.
Cooperative Linux
35
12 Planned Features Since Cooperative Linux is a new project, most of its features are still waiting to be implemented.
12.1 Suspension
Software-suspending Linux is a challenge on standalone Linux systems, considering the entire state of the hardware needs to be saved and restored, along with the space that needs to be found for storing the suspended image. On User Mode Linux suspending [3] is easier only the state of a few processes needs saving, and no hardware is involved. However, in Cooperative Linux, it will be even easier to implement suspension, because it will involve its internal state almost entirely. The procedure will involve serializing the pseudo physical RAM by enumerating all the page table entries that are used in Cooperative Linux, either by itself (for user space and vmalloc page tables) or for itself (the page tables of the pseudo physical RAM), and change them to contain the pseudo value instead of the real value. The purpose of this suspension procedure is to allow no notion of the real physical memory to be contained in any of the pages allocated for the Cooperative Linux VM, since Cooperative Linux will be given a different set of pages when it will resume at a later time. At the suspended state, the pages can be saved to a file and the VM could be resumed later. Resuming will involve loading that file, allocating the memory, and fix-enumerate all the page tables again so that the values in the page table entries point to the newly allocated memory. Another implementation strategy will be to just dump everything on suspension as it is, but on resume—enumerate all the page table entries and adjust between the values of the old RPPFNs2 and new RPPFNs. Note that a
Cooperative Linux
36
suspended image could be created under one host OS and be resumed in another host OS of the same architecture. One could carry a suspended Linux on a USB memory device and resume/suspend it on almost any computer.
12.2 User Mode Linux inside Cooperative Linux
The possibility of running UML inside Cooperative Linux is not far from being immediately possible. It will allow to bring UML with all its glory to operating systems that cannot support it otherwise because of their user space APIs. Combining UML and Cooperative Linux cancels the security downside that running Cooperative Linux could incur.
12.3 Live Cooperative Distributions
Live-CD distributions like KNOPPIX can be used to boot on top of another operating system and not only as standalone, reaching a larger sector of computer users considering the host operating system to be Windows NT/2000/XP.
12.4 Integration with ReactOS
ReactOS, the free Windows NT clone, will be incorporating Cooperative Linux as a POSIX subsystem.
12.5 Miscellaneous
• Virtual frame buffer support. • Incorporating features from User Mode Linux, e.g. humfs 3. • Support for more host operating systems such as FreeBSD.
Cooperative Linux
37
13 Disadvantage The biggest disadvantage is that coLinux runs aside the Windows kernel. It runs on the same hardware abstraction layer that is also called ring0. Inside this CPU abstraction layer, there is no hardware memory protection. This is the same situation as between the Linux or Windows kernel and their device drivers. So a problem in the Linux kernel can bring the Windows kernel down, if Linux violates the Windows address space. Also there are security implications. If a malice user gains root access inside coLinux he can compromise the security of the Windows system as well. Also to load and use coLinux the user has to have administrator rights. (There is the possibility to start coLinux as a service, so it is possible to start coLinux as a normal user, if the user has been granted the right to start the service)
Cooperative Linux
38
14 Conclusion We have discussed how Cooperative Linux works and its benefits. The coLinux is an economical and efficient possibility to program embedded Linux systems directly from a Windows PC. Cooperative Linux has the potential to become an alternative to User Mode Linux that enhances on portability and performance, rather than on security. Moreover, the implications that Cooperative Linux has on what is the media defines as ‘Linux on the Desktop’—are massive, as the world’s most dominant albeit proprietary desktop OS supports running Linux distributions for free, as another software, with the aimed for possibility that the Linux newbie would switch to the standalone Linux. As user friendliness of the Windows port will improve, the exposure that Linux gets by the average computer user can increase tremendously.
Cooperative Linux
39
15 References
Web references: [1] www.dilnetpc.com [2] www.colinux.org [3] www.en.wikipedia.org/wiki/colinux [4] www.sourceforge.net/projets/coLinux [5] www.hesperia.gsfc.nasa.gov/colinux [6] www.user-mode-linux.sf.net [7] www.google.co.in
Book references: [1] Donald E. Knuth. The Art of Computer Programming, volume 1.