On Mon, Jun 26, 2006 at 03:16:08PM -0700, Randy Thelen wrote:
> Anthony Liguori wrote:
>
> >(although it's probably stable enough now to document)
>
> I'm getting that feeling.
>
> >In principle, once you have bring up working, making it work in
> >Xend isn't so bad. Do you have specific questions or are you just
> >looking for a where to begin?
>
> I see this "orange of a problem" and I'm trying to get my fingernail
> under the orange peel.
>
> It appears that in order to get the front-end to talk to the back-
> end, using the standard xenbus and interface type files I seen in
> blkback/ and blkfront/ driver source code directories, that I need to
> begin in Xend. So, I'm looking in Xend and I -think- I get most of
> the architecture relevant here. But, it's not clear to me, yet,
> exactly what Xend asks of the back end driver in order to get the
> system going.
>
> For example, when it's decided that a blk back end will be used,
> blkif.py is run and part of what appears to happen is that the dom0
> blk driver is kicked somehow (!?) and a Python Event is used (in
> DevController.py) with an xswatch() call to wait for the backed to
> startup. And, it seems that the trigger to observing the startup is
> complete is the back end putting some data into XenStore (into
> statusPath = backpath + '/' + HOTPLUG_STATUS_NODE).
Attached are some notes of mine. They are quite old, but I think it all is
pretty much relevant.
Basically, a backend watches /local/domain/0/backend/<deviceClass> and a
frontend watches /local/domain/<domID>/device/<deviceClass>. When the tools
write into those directories in the store, the drivers get a watch fired, and
check those directories to see the new device details. The new internal state
is created based on that.
If you are using the normal Xenbus code, then you can register your device
driver with the Xenbus layer, and much of this is done for you.
The drivers themselves use a simple state machine to handshake between front
and backends.
The backends use hotplug / udev events inside domain 0 to trigger scripts for
simple bringup/teardown stuff, like attaching new vifs to bridges or
whatever. The tools watch for a specific node to be written in the store to
indicate that this hotplug phase has succeeded (it's usually the one that does
the final sanity checking and often has to bail out).
HTH,
Ewan.
drivers.txt
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home