Xen devel - Jun 2006 - Is there example code and/or documentation for developing a Xen back-end/front-end driver pair?

Folks --

I''m walking through all the Xen Python code and driver code to  
determine how to build a custom back-end/front-end driver pair.  I''m  
not using any of the existing transport types (blkif, netif, etc.).   
So, I need to start from scratch supporting configuration file  
elements in Xen down to the drivers in the kernel.

If there are any good pointers as to how to build something new from  
the ground up within the framework of the existing Xen Daemon and be- 
fe pairing, I''d really like to read it.

-- Randy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Randy Thelen wrote:
> Folks --
>
> I''m walking through all the Xen Python code and driver code to 
> determine how to build a custom back-end/front-end driver pair. 
I''m
> not using any of the existing transport types (blkif, netif, etc.).  
> So, I need to start from scratch supporting configuration file 
> elements in Xen down to the drivers in the kernel.
>
> If there are any good pointers as to how to build something new from 
> the ground up within the framework of the existing Xen Daemon and 
> be-fe pairing, I''d really like to read it.
No.  It has changed too many times (although it''s probably stable
enough
now to document).

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?

Regards,

Anthony Liguori


> -- Randy
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

I''m trying to figure out how this aspect of Xend works,  
specifically.  :-)

Any pointers there?  Or, am I way out in the weeds?

-- Randy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ewan Mellor wrote:
> 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,
IHI {It Helps Indeed!}  Thanks.  Could I encourage you to post those  
on the XenSource Wiki?

-- Randy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 26, 2006 at 03:45:04PM -0700, Randy Thelen wrote:
> Ewan Mellor wrote:
> 
> >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,
> 
> IHI {It Helps Indeed!}  Thanks.  Could I encourage you to post those  
> on the XenSource Wiki?
I thought someone had already (obviously not).  I''ve put them on a
XenSplitDrivers page.

Cheers,

Ewan.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel