Okay,
I guess I've been like everybody, just expecting somebody else to reply to this
message (either that or I've missed the reply !). As nobody appears to have
done so, I guess I'll need to do it ;)
>Hi, my name is Mark Hurenkamp, and I've been
>following this list ever since it first got started.
>I must say, I'm quite impressed with the current
>state of development, and the speed at which
>features get implemented.
[snip]
>Anyway, recently, some of my colleagues and I
>started a special interest group, to study Linux
>development, and what our company can do with it.
>(we work for Philips Tass, which is a software
>group within Philips doing mostly embedded
>applications for a.o. consumer electronics).
[snip]
>What I'd like to know is, is there any sort of sub-system
>which we could develop (the six of us), or maybe there
>are several things you would like us to concentrate
>on? I was thinking about maybe emulation of a specific
>hardware device, or develop parts of the GUI.
>(also depending on interrests of my colleagues)
Well, I'd also like to hear opinions from Kevin and Ulrich, but as most core
issues with the kernel module now appear to be in the hands of specific people,
I guess you'd be best off working on plugins. Here are a few things you could
attempt:
(1) Port more devices from BOCHS. We'll need them anyway !
(2) Separate out the hardware devices in libbochs.so into multiple
plugins. Currently, all devices ported from BOCHS are in one
plugin (this was done so that there would be minimal porting
effort). However, a situation where each device has its own plugin
is much more optimal. I suggest taking the following approach:
first split off the "general" BOCHS support code into a library.
Then move each device into its own plugin directory, and link them
all to the BOCHS support library. That way porting effort of new
devices is minimal.
(3) Something I have been thinking about for a while: eventually, we
want to support VM orthogonal persistance (i.e. suspend/resume capability).
In order to do that properly, we need to not only dump the CPU state
and the physical memory to a file, but also the state of each hardware
device (so they don't have to be reinitialised by the guest !)
This is the way I was planning to implement this: when doing
plugin_init(), each plugin needs to return a pointer to a plugin
configuration structure to the main user program. This structure would
look something like
struct plugin_config {
void * persistant_data;
int size;
};
When the VM suspends, the user program dumps the persistant_data
with size size to the VM-core file, together with the CPU state and
v-physical memory. When it resumes, it reloads the plugin with the
persistant data from the file, so the plugin returns into its
original state.
What needs to be done: all plugin "state variables", that need to
be saved across a suspend, need to be separated into a persistant
structure, and the rest of the plugin needs to be modified to access
this structure. Also, the plugin system needs to be changed to
work with plugin_config structure. Finally, a useful memory dump
needs to be made (I was thinking of using ELF file format to store
this --- but anyway, by that time we can have another look at it ;).
>Also I'd like to hear suggestions about how we can
>best get started with all this.
I guess you should read through the code and make sure you understand it.
The virtualisation paper will help. If you're working on plugins the user
program is especially important, and the internal workings of the kernel
module slightly less.
-- Ramon
