|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] protecting xen startup
Xend makes concurrency control much easier, provides a central point of
contact regarding machine state and demuxes the virtual consoles of the
domain. You'd have to address these problems in addition to combining the
tools, which would take a fair bit of hacking to do properly.
okay.
assuming that 1) i don't want a central point of contact i only want
_one_ point of contact and 2) i can live without virtual consoles
until i understand the code enough and can get away with
using ssh logins instead:
would this be a simple enough task for someone not entirely
familiar with xen's code [but who has developed a number of
20k+ line python projects over the past four years]?
You'd need to be fairly familiar with Xen, particularly the virtual device
channels. There's a general purpose transport for control messages
between domain0 and other domains. Multiple messages are sent to and from
Xend in order to set up every virtual device. You can't do without these,
so you'd have to find some way of doing this.
As Rolf said, you do still need a central point of contact in the system
for some operations, in order to ensure safety. The main reason for this
(imo) is to prevent concurrent accesses to domain0's control interface.
You could have a daemon to take care of this or write a Linux device
driver to access the control interface for you.
HTH,
Mark
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
|
|