[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Where can I find some tutorial or manual on how to use xenstore?
I also agree that this would be very useful, and I think the drivers are stable enough now that it's a good idea. In addition to the generic xend integration, it would be quite good if the skeleton frontend/backend contained minimal demonstrator code to set up a device channel (a.k.a. shared memory page and event mapping) between the two VMs. We've talked about having something like this in the tree in the past, it would clearly be useful for people wanting to write new drivers, but I think there was fear that it would rot too quickly (and it certainly would have in the past). If the skeleton driver did something simple but measurable (for correctness) like ping-pong between the frontend and backend, we could add it to XenRT and make sure that it stayed up to date. just a thought... a. On 6/29/06, Ewan Mellor <ewan@xxxxxxxxxxxxx> wrote: On Thu, Jun 29, 2006 at 02:53:26PM +0100, Nick Logan wrote: > Ewan Mellor wrote: > > >On Wed, Jun 28, 2006 at 04:20:51PM +0100, Nick Logan wrote: > > > > > > > >>Ewan Mellor wrote: > >> > >> > >> > >>>On Wed, Jun 28, 2006 at 02:38:15PM +0100, Nick Logan wrote: > >>> > >>> > >>> > >>> > >>> > >>>>The driver was started outside of xend, using a varient of Jacob's > >>>>buscreate program to set the necessary values in xenstore. As this a > >>>>3rd party driver, I'm looking for a solution that does not involve xm > >>>>or xend changes, if that's possible. I'll take a look at the blktap > >>>>patches to see if that helps. > >>>> > >>>> > >>>> > >>>> > >>>Xend is explicitly bringing the devices back up on restore. If you > >>>deliberately bypass it, then you are going to have to do that bringup > >>>yourself. > >>> > >>>Ewan. > >>> > >>> > >>> > >>> > >>I guessed that would be the case. The bringup for a restore would be > >>quite straighforward but more complex for migration. Has anyone > >>suggested hooks for xend to deal with 3rd party drivers so that it could > >>initialise and restore devices that are supported by these drivers? > >>This would enable new drivers to be implemented without changes to xend. > >> > >> > > > >One would have to write a device handler that parsed generic config, and > >then > >passed it through to the store unaltered, and then have hotplug scripts > >that > >could cope with this unparsed config. At the moment, the driver backends > >do > >special-case things like generating a MAC address when none is supplied, > >converting device names to their major:minor, that kind of thing. There > >isn't > >a generic device path; adding one wouldn't be hard. > > > >Ewan. > > > > > Can I just confirm what your proposal is: > > Add a generic device config to the xm config file that would contain the > driver id, virtual device, physical device ..... > Add a generic device handler to xend that would pass the unparsed > generic config through to xenstore. > Add a hotplug script that would parse the unparsed config in xenstore > and start the driver. > When saving a domain, xend would save the generic device config. > xend would call restore for the generic devices. > > If that's correct, I'll find some time to investigate how this could done. Yes, that's it. It sounds like something that would be very useful. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |