/usr/share/doc/user-mode-linux-doc/html/projects.html is in user-mode-linux-doc 20060501-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type">
<title>UML Projects</title>
</head>
<body alink="#FF0000" vlink="#55188A" link="#0000EF" bgcolor="#FFFFFF" text="#000099">
<table border="0">
<tr align="left">
<td valign="top">
<table border="0">
<tr align="left"><td valign="top" >
<img src="uml-small.png" height="171" width="120"/>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">
<font size="-1"><a href="index.html">Site Home Page</a></font>
<br>
<font size="-1"><a href="http://uml.harlowhill.com">The UML Wiki</a></font>
<br>
<font size="-1"><a href="http://usermodelinux.org">UML Community Site</a></font>
<br>
<font size="-1"><a href="roadmap.html">The UML roadmap</a></font>
<br>
<font size="-1"><a href="uses.html">What it's good for</a></font>
<br>
<font size="-1"><a href="case-studies.html">Case Studies</a></font>
<br>
<font size="-1"><a href="kernel.html">Kernel Capabilities</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/dl-sf.html">Downloading it</a></font>
<br>
<font size="-1"><a href="run.html">Running it</a></font>
<br>
<font size="-1"><a href="compile.html">Compiling</a></font>
<br>
<font size="-1"><a href="install.html">Installation</a></font>
<br>
<font size="-1"><a href="skas.html">Skas Mode</a></font>
<br>
<font size="-1"><a href="patches.html">Incremental Patches</a></font>
<br>
<font size="-1"><a href="tests.html">Test Suite</a></font>
<br>
<font size="-1"><a href="devanon.html">Host memory use</a></font>
<br>
<font size="-1"><a href="fs_making.html">Building filesystems</a></font>
<br>
<font size="-1"><a href="faq.html">Troubles</a></font>
<br>
<font size="-1"><a href="contrib.html">User Contributions</a></font>
<br>
<font size="-1"><a href="links.html">Related Links</a></font>
<br>
<font size="-1"><a href="todo.html">The ToDo list</a></font>
<br>
<font size="-1"><a href="projects.html">Projects</a></font>
<br>
<font size="-1"><a href="diary.html">Diary</a></font>
<br>
<font size="-1"><a href="thanks.html">Thanks</a></font>
<br>
<font size="-1"><a href="contacts.html">Contacts</a></font>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">Tutorials<br>
<font size="-1"><a href="UserModeLinux-HOWTO.html">The HOWTO (html)</a></font>
<br>
<font size="-1"><a href="UserModeLinux-HOWTO.txt.gz">The HOWTO (text)</a></font>
<br>
<font size="-1"><a href="hostfs.html">Host file access</a></font>
<br>
<font size="-1"><a href="input.html">Device inputs</a></font>
<br>
<font size="-1"><a href="shared_fs.html">Sharing filesystems</a></font>
<br>
<font size="-1"><a href="fs.html">Creating filesystems</a></font>
<br>
<font size="-1"><a href="resize.html">Resizing filesystems</a></font>
<br>
<font size="-1"><a href="networking.html">Virtual Networking</a></font>
<br>
<font size="-1"><a href="mconsole.html">Management Console</a></font>
<br>
<font size="-1"><a href="debugging.html">Kernel Debugging</a></font>
<br>
<font size="-1"><a href="honeypots.html">UML Honeypots</a></font>
<br>
<font size="-1"><a href="gprof.html">gprof and gcov</a></font>
<br>
<font size="-1"><a href="xtut.html">Running X</a></font>
<br>
<font size="-1"><a href="trouble.html">Diagnosing problems</a></font>
<br>
<font size="-1"><a href="config.html">Configuration</a></font>
<br>
<font size="-1"><a href="slack_readme.html">Installing Slackware</a></font>
<br>
<font size="-1"><a href="arch-port.html">Porting UML</a></font>
<br>
<font size="-1"><a href="iomem.html">IO memory emulation</a></font>
<br>
<font size="-1"><a href="2G-2G.html">UML on 2G/2G hosts</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/lksct/index.html">Adding a UML system call</a></font>
<br>
<font size="-1"><a href="nesting.html">Running nested UMLs</a></font>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">How you can help<br>
<font size="-1"><a href="help-gen.html">Overview</a></font>
<br>
<font size="-1"><a href="help-doc.html">Documentation</a></font>
<br>
<font size="-1"><a href="help-userspace.html">Utilities</a></font>
<br>
<font size="-1"><a href="help-kernel-v1.html">Kernel bugs</a></font>
<br>
<font size="-1"><a href="projects.html">Kernel projects</a></font>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">Screenshots<br>
<font size="-1"><a href="net.html">A virtual network</a></font>
<br>
<font size="-1"><a href="x.html">An X session</a></font>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">Transcripts<br>
<font size="-1"><a href="login.html">A login session</a></font>
<br>
<font size="-1"><a href="debug-session.html">A debugging session</a></font>
<br>
<font size="-1"><a href="slackinst.html">Slackware installation</a></font>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">Reference<br>
<font size="-1"><a href="switches.html">Kernel switches</a></font>
<br>
<font size="-1"><a href="slack_readme.html">Slackware README</a></font>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">Papers<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/als2000/index.html">ALS 2000 paper (html)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/als2000.tex">ALS 2000 paper (TeX)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/als2000/slides.html">ALS 2000 slides</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/lca2001/lca.html">LCA 2001 slides</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/ols2001/index.html">OLS 2001 paper (html)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/ols2001.tex">OLS 2001 paper (TeX)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/als2001/index.html">ALS 2001 paper (html)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/als2001.tex">ALS 2001 paper (TeX)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/ists2002/umlsec.htm">UML security (html)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/lca2002/lca2002.htm">LCA 2002 (html)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/wvu2002/wvu2002.htm">WVU 2002 (html)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/ists_rt/ists_rt.htm">Security Roundtable (html)</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/ols2002/ols2002.html">OLS 2002 slides</a></font>
<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/slides/lwe2005/LWE2005.html">LWE 2005 slides</a></font>
</td></tr>
<tr align="left"><td valign="top" bgcolor="#e0e0e0">Fun and Games<br>
<font size="-1"><a href="http://user-mode-linux.sourceforge.net/cgi-bin/hangman">Kernel Hangman</a></font>
<br>
<font size="-1"><a href="sdotm.html">Disaster of the Month</a></font>
</td></tr>
</table>
</td>
<td valign="top" align="left">
<center>
<h3>UML Projects</h3>
</center>
Here's a list of interesting things that need doing, but which I'm not
going to have time for any time soon. These are all going to happen
after UML V1.0 hits the streets. If you're interested in working
on any of these and want pointers, help, etc, contact the
<a href="http://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel">UML devel list</a>.
<a name="Architecture Ports"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">Architecture Ports</font>
</b>
</td>
</tr>
</table>
<blockquote head="Architecture Ports">
UML needs to be ported to other Linux architectures
besides i386. This isn't very hard. The ppc port is nearly working
at this point, and that has provided a lot of information that other
ports will need. This is written up
<a href="arch-port.html">here</a>.
</blockquote>
<a name="OS Ports"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">OS Ports</font>
</b>
</td>
</tr>
</table>
<blockquote head="OS Ports">
It also needs to be ported to other operating systems.
Other Unixes would probably be easiest. An OS needs some way of
intercepting Linux system calls in order for a port to be possible.
There are other needs, but they can probably be worked around if
they're not met. A Windows port would be most interesting. NT
apparently has the basic capabilities to run UML. Because UML
provides a secure virtual machine, running it on Windows would provide
a sandbox in which users could run untrusted code (like the email
virus du jour) safely. It would be very amusing to have Linux provide
a capability for Windows that Windows can't provide for itself.
<br>
It turns out that Michael Vines has written what amounts to the core
of a Windows port. It's a Windows app which intercepts Linux system
calls and interprets them itself. This is the critical part of UML.
If this works, everything else can probably be made to work. So, if
you're interested in working on this and want a head start, see
<a href="http://line.sourceforge.net/">his
page</a> for the details.
</blockquote>
<a name="Native driver development"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">Native driver development</font>
</b>
</td>
</tr>
</table>
<blockquote head="Native driver development" post="5556203" name="uml-hcd-2.4.3.patch">
It is possible to allow direct access to hardware. This would allow native
drivers to run (and be debugged) in userspace. This requires that the host
provide access to io space (there is currently the ability to map io
memory into a process address space, which I think satisfies this),
and provide something to sit on the device irq and notify the
userspace driver of interrupts. I think this can be done with a stub
driver which probes the device at boot time, provides a file that the
userspace driver can open, and sends a SIGIO down the file descriptor
whenever the device interrupts. The thing I'm not sure about is
timing. If the driver needs to do stuff with interrupts disabled,
then that would make a userspace version hard, since processes can't
run without interrupts on.
<p>
As of 15 Apr 2001, it is possible to do USB
development under UML. Johan Verrept
<a href="http://www.geocrawler.com/lists/3/SourceForge/709/0/5556203">posted</a>
a <a href="patches/uml-hcd-2.4.3.patch">patch</a> which allows a USB
device driver in UML to control a physical USB device on the host.
</blockquote>
<a name="hostfs extensions"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">hostfs extensions</font>
</b>
</td>
</tr>
</table>
<blockquote head="hostfs extensions">
hostfs is now used to access filesystems on the host, but it's
potentially much more general than that. It's separated cleanly into
kernel and userspace pieces, with the userspace code dealing with the
external data.
<p>
The simplest extension would be to move the user code to a remote
machine and put a simple RPC mechanism between the kernel and
userspace pieces. This would allow mounting of a remote directory
into a UML, similar to the userspace nfs daemon.
<p>
A more interesting possibility is to make the userspace host code deal
with non-filesystems that can be made to look like filesystems. There
are lots of databases which might be interesting to represent as
filesystems:
<ul>
<li>
SQL databases - each row is a directory, with each column a file
containing the entry for that row and column
</li>
<li>
File databases like /etc/passwd and /etc/group - each entry is a
directory with columns as files like the SQL scheme above
</li>
<li>
Network databases like NIS and BIND
</li>
</ul>
Other possibilities include
<ul>
<li>
networks - with each machine getting a directory containing
information about that box
</li>
<li>
people and users
</li>
</ul>
And there are probably lots of other possibilities. Anything that can
at all be reasonably made to look like a file or filesystem could
be mounted inside UML.
<p>
To make this work, all that's needed is a rewrite of
arch/um/fs/hostfs/hostfs_user.c. It implements the operations on the
underlying objects, which currently are host files. If you can
implement those same operations for some other kind of object, then
that object, or a set of them, can be mounted inside a UML and
operated on as files.
<p>
Storing the same data in multiple places and mounting them jointly as
a single hosfs filesystem offers other possibilities as well:
<ul>
<li>
Dumping a directory into a filesystem into a database and having
hostfs provide access to both would allow normal file access to the
filesystem plus queries to the database through a mechanism such as an
ioctl or a virtual filesystem on the side. So, you'd get both normal
access to the filesystem plus the ability to do database queries on it.
</li>
<li>
Mounting many almost-identical directories from multiple machine on a
single hostfs mount point would allow software to be installed to all
the machines simulataneously with a single install command inside the
virtual machine.
</li>
</ul>
</blockquote>
<a name="SMP support"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">SMP support</font>
</b>
</td>
</tr>
</table>
<blockquote head="SMP support">
Enabling SMP in UML would allow it to emulate a multiprocessor box.
Getting this working should be fairly straightforward. I did have it
working in early 2000, but turned it off to work on the UP side of
things.
<p>
Here's what needs to be done:
<ul>
<li>
Uncomment the SMP config in arch/um/config.in, run your favorite
config, and turn it on
</li>
<li>
Get UML to compile - there's been some bitrot since this last worked,
so the some of the kernel headers don't agree any more with what's in
UML, and I've put in some #error directives where I've noticed there
needs to be some thought about SMP.
</li>
<li>
Audit the UML arch code, looking for global data that needs locking.
There isn't very much of it. I did the audit in a couple of days, and
didn't miss very much.
</li>
<li>
Debug it. Bang on it until you stop hitting races.
</li>
<li>
Send in the patch.
</li>
</ul>
</blockquote>
<a name="UML Clustering"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">UML Clustering</font>
</b>
</td>
</tr>
</table>
<blockquote head="UML Clustering">
DSM stands for Distributed Shared Memory, where the nodes of a cluster
share a portion of their memory through some kind of special
interconnect.
<p>
This can be done with UML because UML's physical memory is really
virtual memory on the host, so it can be mapped and unmapped. So, the
idea is to spread a single UML instance over multiple hosts by running
a virtual processor on each host and partitioning UML physical memory
between them. A page that's present on one node will be unmapped from
the others. If one of the other nodes accesses it, it will fault, and
a new low-level fault handler will figure out what node currently has
it, and request that it be sent over. The other node will unmap it,
and copy it over to the requesting node, which will map it in to the
appropriate location and continue running.
<p>
This will get a UML-based Single-System Image (SSI) cluster up and
running. It will be very inefficient because there are data
structures that the kernel references very frequently. The pages that
contain this data will be constantly being copied from node to node
and the nodes will be spending much of their time waiting for that to
happen.
<p>
There are two avenues through which this can be fixed. One follows
from the observation that this cluster is an extreme form of NUMA,
with no global memory and very expensive access to other nodes' local
memory. So, the ongoing NUMA work going into Linux will help this.
Plus, UML will effectively make NUMA hardware available to everyone
who runs Linux, which will hopefully pull more people into the effort
and speed it up.
<p>
The other is to start replacing the shared memory communication with
an RPC-based communication mechanism. While the NUMA work will reduce
the amount of inter-node chatter, an RPC mechanism will make the
remaining communication much more efficient. The ultimate outcome of
this effort will be a standard SSI cluster implementation which can
run both with physical nodes or virtual ones.
</blockquote>
<a name="UML as a normal userspace library"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">UML as a normal userspace library</font>
</b>
</td>
</tr>
</table>
<blockquote head="UML as a normal userspace library">
UML normally runs as a standalone executable, but there's no reason
bthat it can't be packaged slightly differently, as a library which
other applications could link against. Those apps would gain access
to all the functionality in the kernel, including
<ul>
<li>
memory allocation - these are specialized to be fast and scalable.
In addition the virtual memory allocator is able to defragment memory
efficiently with a buddy system algorithm.
</li>
<li>
memory management - built-in swapping and cache size control. With
some work, the userspace swapping code could be used to tell the host
kernel what memory the application doesn't really need, allowing
userspace and kernelspace to cooperate in getting the best performance
from the system.
</li>
<li>
virtual memory and multiple address spaces - these are things which
libc doesn't provide, except by calling into the kernel to get them.
They can be used to jail some of the application's threads, if it is
running something it doesn't trust. With the addition of highmem
support to UML, this could be used to transparently provide access to
more than 4G of address space.
</li>
<li>
threads - these are specialized to be low-overhead and fast, as is the
scheduler.
</li>
<li>
filesystems - the filesystems can be thought of hierarchical storage
systems for the application's internal data. They can be mounted on
an internal ramdisk, making them private and non-persistent, or an a
host file, making them persistent and possibly shared.
</li>
<li>
the full network stack and network devices - this is interesting when
combined with the presence of a filesystem inside the application. It
could export the filesystem via NFS or another remote filesystem
protocol to the outside world.
</li>
</ul>
Here are some examples of how these capabilities can be used:
<ul>
<li>
Apache could store its configuration in an internal filesystem and
export it to the outside world over the network. All of the Apaches
in a server farm could store their configurations in an internal
filesystem and export them to the outside world over their networks.
A central server mounts them all and uses information about the load
on each machine to tweak the settings of its Apache so that the server
does as much work as possible without causing it to be overloaded.
</li>
<li>
Alternatively, the Apaches could all import their configurations from
a central location so that when a change is made on the central
server, all of the servers immediately see the change. This would be
useful for things like virtual server configuration. Create the new
virtual server configuration by creating the appropriate directories
and files in the configuration filesystem and all of the web servers
importing that configuration would immediately start serving the new
virtual domain.
</li>
<li>
Combine the two previous examples, with each server exporting
performance-related configuration items so they can be individually
tweaked on the fly, but importing the global configuration items that
need to be shared across the entire server farm.
</li>
<li>
These servers could use the virtual memory and jailing abilities of
UML to accept code from web clients and run it. These pieces of code
would be run as UML processes, jailing them inside restricted
environments with their own private address spaces, allowing them to
change their own data, but providing no access to any other data. To
prevent these threads from consuming too much CPU and preventing the
servers from doing their normal work, they could be given a lower
priority than the normal Apache threads, so that the UML scheduler
will only run a client's thread when the server would otherwise be idle.
</li>
<li>
An interactive application could store its UI in an internal
filesystem and export it to the host. External scripts could then
navigate around that filesystem, activating parts of the interface,
which would effectively provide scripting to applications which don't
have it built-in.
</li>
<li>
A script could watch the exported filesystem for events such as a dialog
box being opened and fill in the fields with defaults from information
sources that the application knows nothing about. The script could
simply remember the last set of values for that dialog box and fill
them in the next time. Or it could be watching a number of
applications, copying information from one to the other. For example,
if the user has just looked up a particular person's calendar and is
now starting to compose an email message, the script could look up
that person's email address in its own database, and put it in the
'To' field of the new message composition window.
</li>
</ul>
</blockquote>
<a name="Clusterized applications"/><table width="100%" bgcolor="#e0e0e0">
<tr>
<td>
<b>
<font color="black">Clusterized applications</font>
</b>
</td>
</tr>
</table>
<blockquote head="Clusterized applications">
Combine the ideas of using UML as a cluster and using it as an
application library and you get an application which can spread itself
over multiple machines and effectively remain a single process. Since
the kernel's data structures and algorithms will preseumably be suited
for clustering already, the more extensively the application uses them
for its own purposes, the more prepared it will be to spread itself
transparently over a virtual cluster.
<p>
Servers would be able to automatically add virtual nodes on new
physical hosts to themselves as the load increased and shut them down
as their load goes back down. And as they do that, some other
clusterized server may be starting to run on those hosts as its load
goes up. This will makes it possible to run one server for each
service on a server farm, rather than one server per machine.
</blockquote>
</td>
</tr>
</table>
<center>
<font size="-1">Hosted at </font>
<a href="http://sourceforge.net">
<img src="http://sourceforge.net/sflogo.php?group_id=429" width="88" height="31" border="0" alt="SourceForge Logo">
</a>
</center>
</body>
</html>
|