<div>This sounds interesting too!</div>
<div> </div>
<div>Could you please tell me the tradeoff's of using this approach i.e. 9p service channel VS</div>
<div>storing the value in the host structures and using the hypercall mechanism?</div>
<div><br>Tradeoff's in terms of efficiency and implementation?</div>
<div> </div>
<div>Thanks!</div>
<div>Cheers!</div>
<div>Sujit<br> </div>
<div><span class="gmail_quote">On 10/25/07, <b class="gmail_sendername">ron minnich</b> <<a href="mailto:rminnich@gmail.com">rminnich@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">You don't need a new hypercall. You need a channel to a service that<br>is provided by the lguest process to the guest OS. You can then use
<br>this channel to communicate requests to the lguest process from the<br>guest, and the lguest process will in turn take action based on those<br>requests, and return status information.<br><br>The lguest process will at least need to acknowledge receipt of the
<br>requests, and that's why a file metaphor is useful.<br><br>So your lguest exports, via 9p, a service containing one file:<br>ctl<br><br>ctl is exclusive-open. The guest writes requests to this file. To<br>issue a request, the guest does this:
<br>open(ctl)<br>write(ctl, "frob me", 7);<br>read(ctl, result, sizeof(result));<br>close(ctl);<br>/* examine 'result' for the success/failure of the request, and causes if any */<br>/* result should contain a string, not binary data */
<br><br>Later, you might find yourself adding bits, so that you might have two files:<br>ctl<br>status<br><br>where status is read-only and communicates information to the guest.<br><br>Plan 9 has used this sort of model for some 20 years now and it has
<br>worked very well.<br><br><br>ron<br></blockquote></div><br>