Site Home Page
The UML Wiki
UML Community Site
The UML roadmap
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Skas Mode
Incremental Patches
Test Suite
Host memory use
Building filesystems
User Contributions
Related Links
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Resizing filesystems
Virtual Networking
Management Console
Kernel Debugging
UML Honeypots
gprof and gcov
Running X
Diagnosing problems
Installing Slackware
Porting UML
IO memory emulation
UML on 2G/2G hosts
Adding a UML system call
Running nested UMLs
How you can help
Kernel projects
A virtual network
An X session
A login session
A debugging session
Slackware installation
Kernel switches
Slackware README
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
WVU 2002 (html)
Security Roundtable (html)
OLS 2002 slides
LWE 2005 slides
Fun and Games
Kernel Hangman
Disaster of the Month
The mconsole protocol needs to be versioned.

The next version of the protocol needs to be more packet-oriented than it is now. In order to pass an arbitrary amount of data back to the client, we need to support replies with multiple packets and to be able to tell when the output is finished.

The current client needs improving:

  • It should be able to control multiple UMLs
  • It should be able to detect new UMLs as they come up
  • Command history should work and should be saved from one session to the next
The mconsole should be able to receive console output and notifications of panics. It should have some sort of intelligent interface for letting the user see or ignore the console output.

There probably needs to be a GUI mconsole client. Emacs and IRC mconsole clients would also be cute.

Its protocol should be versioned.

There needs to be an output socket for each client, rather than the single socket that exists now. This is because one client that slowly receiving packets could cause the socket to nearly fill up, causing packets to another client to overflow it and lose packets. In this case, the slow UML will unfairly cause a different UML to lose packets.

It should be able to act as a gateway to the host.

It should be able to communicate over UDP sockets as well as unix sockets

It should be able to communicate with uml_routers on other hosts

Someone who understands how RPM and debs work should look at the UML packages and at least figure out what's wrong with them.

Better documentation needs to be installed with them. The HOWTO currently isn't build and installed. There also needs to be a README installed in /usr/lib/uml which at least describes what to do with the module tarballs.

The UML test harness should be packaged up somehow. My current thinking is that the tarball could be part of the packages, the install scripts would check for the presence of perl, and if it's there, unpack and install the test harness and test cases in the same way that modules from CPAN are installed.

And the test suite has not been worked on for quite a while. The UML module should be updated so it can be an mconsole client. The test suite should be turned into a real set of tests which can be run as part of the normal build process.

gdb scripts
James Stevenson has written some handy gdb scripts which make it easy to print to the process list and a few other things. These need to be put in the pool, installed in the packages, documented, and expanded.
The mkrootfs script needs to be able to create bootable filesystems from Debian and Debian-based media.

It also needs to be able to construct special-purpose filesystems, such as minimal filesystems that run a single service, such as Apache, sendmail, or bind.

A GUI version of mkrootfs might also be nice.

The filesystem images
Now that we have the COW ubd driver, these should be packaged up separately as RPMS and debs.
Hosted at SourceForge Logo