Hi, I''m trying to figure what causes a probe callback to happen, any quick example? Thanks, Mukesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11/12/2008 03:14, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:> Hi, > > I''m trying to figure what causes a probe callback to happen, any quick > example?New directories appearing in xenstore under /local/domain/x/device/ -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? 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.
Thanks in advance,
Mukesh
Keir Fraser wrote:
> On 11/12/2008 03:14, "Mukesh Rathor"
<mukesh.rathor@oracle.com> wrote:
>
>> Hi,
>>
>> I''m trying to figure what causes a probe callback to happen,
any quick
>> example?
>
> New directories appearing in xenstore under /local/domain/x/device/
>
> -- Keir
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 17/12/2008 03:15, "Mukesh Rathor" <mukesh.rathor@oracle.com> 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> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:
> On 17/12/2008 03:15, "Mukesh Rathor"
<mukesh.rathor@oracle.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel