Here's an idea which is needed for NFS on large installations (especially HA installations) but which is relatively straightforward to implement.
Here's the problem: NFS is very oriented to the value of major and minor numbers. If they change after a client starts using a filesystem, the client will get the dreaded "Stale File Handle" error. This can happen because the server is rebooted with a slightly different hardware configuration or because it's in a high-availability configuration and the failover server has a slightly different hardware configuration.
If one is in an environment with lots of disk - like a SAN or a machine with lots of full SCSI buses, then managing this configuration to keep it consistent by minor device number is often difficult, and can become intractable - and you'll run into periodic Stale File Handle errors when you reconfigure things. In an HA environment this is anathema - it should *NEVER* happen.
One solution is to create a dummy block device driver whose sole purpose is to map its minors to selected devices (by name). This driver would act as a layer of insulation from hardware reconfigurations to make this problem basically go away.
Let's say you call this driver's devices /dev/bredirXX.
If you have a SCSI device chain with target devices 2, 4 and 6, then they would map like this:
/dev/sda => target 2 (minor 0)
/dev/sdb => target 4 (minor 1)
/dev/sdc => target 6 (minor 2)
If you export the filesystem on /dev/sdc via NFS, then adding or deleting any SCSI devices will make NFS come up with a stale file handle.
For example, if you add a SCSI disk with target id 3, then things will now look like this:
/dev/sda => target 2 (minor 0)
/dev/sdb => target 4 (minor 1)
/dev/sdc => target 5 (minor 2)
/dev/sdd => target 6 (minor 3)
This guarantees a stale file handle error if the server moved from the previous configuation to this one. But, a redirection driver can eliminate this...
If you're only exporting one of these devices via NFS, then you only need to manage one device. The driver could be configured to map minors to other devices like this:
#minor device
0 /dev/sdc
Then, when the reconfiguration is made, one can always change the table, but keep the /dev/bredir minors consistent. Given the example reconfiguration above, a revised table which would do that would be:
#minor device
0 /dev/sdd
Now, the change in minors and devices is hidden from NFS and it is fat, dumb and happy -- and so are all your NFS clients.
So, this device only passes along requests to different devices - mapping the major/minors from the /dev/bredir values to the correct underlying values. It's valuable, simple, and a way of getting one's feet wet in a for-real OS development project.
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.
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.
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:
Other possibilities include
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. 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.
Storing the same data in multiple places and mounting them jointly as a single hosfs filesystem offers other possibilities as well:
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.
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.
Send in the patch to UML if you are confidence of its quality.
Enabling SMP in UML would allow it to emulate a multiprocessor box. Getting this working should be fairly straightforward.
Here's what needs to be done:
Send in the patch to UML if you are confidence of its quality.
Most devices in UML are virtual: virtual block device, virtual ethernet, console, tty, etc. However, there is no virtual frame buffer. Frame buffer is a device for graphics output, such as VGA. You need a frame buffer to run X window.
This project is to add a frame buffer device to UML so you can support graphics. Instead of giving you one character-based console and two tty's when you run UML, it can give you a framebuffer display window. You can run X window or other frambuffer application within that framebuffer display window.
There are a couple ways you can approach this. You could implement a virtual VGA device in UML. This requires you to emulate a VGA card hardware and emulate the display with an X window. Once you have this, you should be able to run vgalib applications as well as a striped down version of XFree86 server (XF86_VGA).
An better way is to make use of the linux frame buffer device abstraction (source code under drivers/video/, and documents under Documentation/fb/). Within UML, you will provide a virtual framebuffer device, e.g.,
/dev/fb0This virtual device is actually implemented by UML kernel as an X window client. That is, any operation on the frame buffer will be implemented as X window function call on host. You will need to have some knowledge about Xlib programming.
You need to follow the frame buffer device interface faithfully. For example, /dev/fb* are used as a memory device. So your device driver code must support memory mapping (mmap()) operation. Also, /dev/fb* allows several ioctls on it, by which lots of information about the hardware can be queried and set. So you must support those ioctls as well.
Finally, you can add UML command line option like
fb0=localhost:0,800x600x16which is to open an X window of 800x600 (16 is the depth) using localhost:0 as the DISPLAY variable.
Once you provide such virtual frame buffer device in UML, you can run any framebuffer applications inside UML, such as a special X window server (XF86_FBDev).
You may get some ideas if you take a look at the program Xnest (which runs an X server display within an X window), and VNC (which export a framebuffer to anywhere in the network) on how to dealt with frame buffers (not necessary using the linux fbdev abstraction).
Just like host file system, where you can access the files in the host that you run UML, the host socket system is to allow you to access the socket interfaces in the host.
This has many applications. It allows you to establish a communication channel between a process running in UML and a process running in the real world. For example, you can now browse the world wide web from within UML. You can also telnet to any host from within UML, or run X window client this way.
There are two types of socket, UNIX domain socket and Internet domain socket (IP). You need to support both.
The modifications are rather straight forward. You need to redefine all the socket system call service routines (in UML), and implement them using the socket system call interfaces (provided by the Linux host).
You also need new UML command line options. For unix domain socket, you can define something like
hostsock=/tmp/.X11-unix/X0,Xthis would cause UML kernel to create a /proc/hostsock/X unix socket inside UML, and link it with the host's /tmp/.X11-unix/X0. An application of this is to create /tmp/.X11-unix/X0 in UML as a link to /proc/hostsock/X and be able to run X clients on the host X server without needing the network up.
Internet domain socket (UDP, TCP) is a little bit tricky.