[Lguest] Lguest modification.

Sujit Sanjeev sujit771 at gmail.com
Fri Oct 26 09:15:17 EST 2007


This sounds interesting too!

Could you please tell me the tradeoff's of using this approach i.e. 9p
service channel VS
storing the value in the host structures and using the hypercall mechanism?

Tradeoff's in terms of efficiency and implementation?

Thanks!
Cheers!
Sujit

On 10/25/07, ron minnich <rminnich at gmail.com> wrote:
>
> You don't need a new hypercall. You need a channel to a service that
> is provided by the lguest process to the guest OS. You can then use
> this channel to communicate requests to the lguest process from the
> guest, and the lguest process will in turn take action based on those
> requests, and return status information.
>
> The lguest process will at least need to acknowledge receipt of the
> requests, and that's why a file metaphor is useful.
>
> So your lguest exports, via 9p, a service containing one file:
> ctl
>
> ctl is exclusive-open. The guest writes requests to this file. To
> issue a request, the guest does this:
> open(ctl)
> write(ctl, "frob me", 7);
> read(ctl, result, sizeof(result));
> close(ctl);
> /* examine 'result' for the success/failure of the request, and causes if
> any */
> /* result should contain a string, not binary data */
>
> Later, you might find yourself adding bits, so that you might have two
> files:
> ctl
> status
>
> where status is read-only and communicates information to the guest.
>
> Plan 9 has used this sort of model for some 20 years now and it has
> worked very well.
>
>
> ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/lguest/attachments/20071025/f3142d72/attachment.htm>


More information about the Lguest mailing list