Keir Fraser wrote:
> On 17/12/2008 03:15, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:
>
>> Thanks. Now, that I played around a bit, am going in circles trying to
>> figure how to keep very simple in my messaging driver. Basically,
>> I'd like to keep it symmetric, no frontend/backend, just one file,
>> dynamically loadable, kernel driver. When a driver is loaded in domU, it
>> broadcasts ring-ref/event-chnl and causes dom0 callback to wake up and
>> act on it. Since domU can't write to /local/domain/0/blah/bleh, is there
>> some other generic way to broadcast it?
>
> No, the whole point is that a domU cannot disturb dom0 unless a rendezvous
> point has been set up by the tool stack.
>
> Who are the messages to be picked up by? Tool stack? In which case why not
> just stuff messages via a well-known /local/domain/x/... xenstore node which
> tools would watch for all alive domains x?
>
> -- Keir
Well, combination. Some messages could be picked up by tool stack,
database might be interested in other, and a file system/vol-manager
closely associated with the database interested in yet other messages
that are related to dynamically changing of resources. Things are still
being architected, with feedback from the DB folks. It must also be
supported on multiple platforms, and they'd want a uniform interface.
Anyways, I should be to do it in the current infrastructure,
/local/domain/x like you suggest, and prototype something.
As always, thanks for your prompt help.
Mukesh
>
>> I'd like to avoid a user level
>> script. It almost appears xenbus_watch_path() may allow me to set
>> callback on /local/domain/*/blah/bleh, but I don't have the
>> xenbus_device ptr as it seems provided by xenbus_driver{} callbacks.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home