xenbus callback probe...

xenbus callback probe...

[Mukesh Rathor]

Hi,

I'm trying to figure what causes a probe callback to happen, any quick example?

Thanks,
Mukesh

Re: xenbus callback probe...

[Keir Fraser]

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

Re: xenbus callback probe...

[Mukesh Rathor]

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
 >

Re: xenbus callback probe...

[Keir Fraser]

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.

Re: xenbus callback probe...

[Mukesh Rathor]

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.
 >