I have committed a moderately large change to the device driver infrastructure in Xen. This change takes large pieces of code from Rusty Russell''s skeleton driver, but with this work refactored so that it is available to all Xenbus-based split drivers. This change and it''s relation to Rusty''s work is discussed in an email that will follow on immediately. My intention is that we solidify the driver layer around this architecture as we head for a Xen 3.0 release. A number of subtle bugs have been addressed by this change, and the code is now shorter and simpler, which should make it easier for new drivers to be written too. I have ported the net and block drivers to this, but not blktap, tpmfront, or tpmback. I shall be making a first pass over those three drivers very shortly, but I would appreciate it if those people who are interested in those drivers could help with testing and tweaking, as obviously I don''t understand them quite as well as the major drivers. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Magenheimer, Dan (HP Labs Fort Collins)
2005-Nov-15 15:25 UTC
RE: [Xen-devel] Driver Architecture Changes
Hmmm... It appears that this has completely broken the block drivers for ia64. Since it is such a massive change, I''d imagine it will be difficult to track down the problem(s). I had rather hoped that we were done with this kind of massive change pre-3.0. With Xen/ia64 block devices working in the main tree, I was going to ask if it might make sense for some basic Xen/ia64 tests to be part of the pre-commit regression test, but alas I guess I am too late. Ewan, would you be willing to work with Kevin to get your re-architected driver infrastructure working on Xen/ia64? Hopefully it will be easier than I fear but utilizing your direct expertise with the new architecture, it will be much easier than Kevin figuring it out from scratch. Until this is all working again, it won''t make much sense to merge xen-ia64-unstable into xen-unstable, and there are some fairly critical bug fixes already waiting. Thanks, Dan> From: Ewan Mellor <ewan@xensource.com> > Subject: [Xen-devel] Driver Architecture Changes > To: Xen-devel <xen-devel@lists.xensource.com> > Message-ID: <20051115001511.GA28109@leeni.uk.xensource.com> > Content-Type: text/plain; charset=us-ascii > > I have committed a moderately large change to the device > driver infrastructure > in Xen. This change takes large pieces of code from Rusty > Russell''s skeleton > driver, but with this work refactored so that it is available to all > Xenbus-based split drivers. This change and it''s relation to > Rusty''s work is > discussed in an email that will follow on immediately. > > My intention is that we solidify the driver layer around this > architecture as > we head for a Xen 3.0 release. A number of subtle bugs have > been addressed by > this change, and the code is now shorter and simpler, which > should make it > easier for new drivers to be written too. > > I have ported the net and block drivers to this, but not > blktap, tpmfront, or > tpmback. I shall be making a first pass over those three drivers very > shortly, but I would appreciate it if those people who are > interested in those > drivers could help with testing and tweaking, as obviously I > don''t understand > them quite as well as the major drivers._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Nov 15, 2005 at 07:25:10AM -0800, Magenheimer, Dan (HP Labs Fort Collins) wrote:> Ewan, would you be willing to work with Kevin to get your > re-architected driver infrastructure working on Xen/ia64?Certainly. Let me know what you need. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Magenheimer, Dan (HP Labs Fort Collins)
2005-Nov-15 16:58 UTC
RE: [Xen-devel] Driver Architecture Changes
Thanks! But false alarm... when I recloned, rebuilt, rebooted and tried again, it seems to work! I think I had some inconsistencies because I had some hg problems yesterday. That said, it still might be a good idea to bring up the ia64 boxes that arrived at Cambridge last month and incorporate them into some regression testing. Sorry for any inconvenience! Dan> -----Original Message----- > From: Ewan Mellor [mailto:ewan@xensource.com] > Sent: Tuesday, November 15, 2005 8:34 AM > To: Magenheimer, Dan (HP Labs Fort Collins) > Cc: Tian, Kevin; xen-devel@lists.xensource.com; > xen-ia64-devel@lists.xensource.com > Subject: Re: [Xen-devel] Driver Architecture Changes > > On Tue, Nov 15, 2005 at 07:25:10AM -0800, Magenheimer, Dan > (HP Labs Fort Collins) wrote: > > > Ewan, would you be willing to work with Kevin to get your > > re-architected driver infrastructure working on Xen/ia64? > > Certainly. Let me know what you need. > > Ewan. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello Ewan, I am following the changes with the TPM driver pair. I was wondering what causes the ''add'' action to be invoked on the hotplug scripts and why would one not see a remove action if a previous ''add'' action was encountered and it had finished successfully. Regards, Stefan xen-devel-bounces@lists.xensource.com wrote on 11/15/2005 10:33:35 AM:> On Tue, Nov 15, 2005 at 07:25:10AM -0800, Magenheimer, Dan (HP Labs > Fort Collins) wrote: > > > Ewan, would you be willing to work with Kevin to get your > > re-architected driver infrastructure working on Xen/ia64? > > Certainly. Let me know what you need. > > Ewan. > > _______________________________________________ > 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
On Wed, Nov 16, 2005 at 04:40:34PM -0500, Stefan Berger wrote:> Hello Ewan, > > I am following the changes with the TPM driver pair. I was wondering > what causes the ''add'' action to be invoked on the hotplug scripts and why > would one not see a remove action if a previous ''add'' action was > encountered and it had finished successfully.The add action occurs when the device is registered with the kernel (xenbus_probe.c:xenbus_probe_node), and you should get a remove when the device is no longer referenced. Once the frontend driver has flushed through and closed down, it switches to state Closed, which is seen in the backend driver''s otherend_changed function (blkback/xenbus.c:frontend_changed for example). This then calls device_unregister, which ought to be enough to ensure that no-one is referencing the device, and so the kernel will clean up the sysfs entries etc and you will get a remove hotplug event. If that''s not happening, then there may be a bug which needs further investigation. HTH, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor <ewan@xensource.com> wrote on 11/17/2005 12:26:45 PM:> On Wed, Nov 16, 2005 at 04:40:34PM -0500, Stefan Berger wrote: > > > Hello Ewan, > > > > I am following the changes with the TPM driver pair. I was wondering > > what causes the ''add'' action to be invoked on the hotplug scripts andwhy> > would one not see a remove action if a previous ''add'' action was > > encountered and it had finished successfully. > > The add action occurs when the device is registered with the kernel > (xenbus_probe.c:xenbus_probe_node), and you should get a remove when the > device is no longer referenced. Once the frontend driver has flushedthrough> and closed down, it switches to state Closed, which is seen in thebackend> driver''s otherend_changed function (blkback/xenbus.c:frontend_changedfor> example). This then calls device_unregister, which ought to be enoughto> ensure that no-one is referencing the device, and so the kernel willclean up> the sysfs entries etc and you will get a remove hotplug event.The mistake I had made was not to switch to the Closed state. So now I am seeing the remove as well. Thanks. Another question: I see that the .suspend function is not used in the frontends anymore, but the structure still has that member. Is the suspend member about to be removed?> > If that''s not happening, then there may be a bug which needs further > investigation.Was my bug. Stefan> > HTH, > > Ewan._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Nov 17, 2005 at 02:51:38PM -0500, Stefan Berger wrote:> Another question: I see that the .suspend function is not used in the > frontends anymore, but the structure still has that member. Is the suspend > member about to be removed?The block and net drivers don''t need this at the moment, but it seems like some driver may need it some time, so no, we won''t be removing it. It does no harm to support it, and it may be useful to someone. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Nov 17, 2005 at 09:37:37PM +0000, Ewan Mellor wrote:> On Thu, Nov 17, 2005 at 02:51:38PM -0500, Stefan Berger wrote: > > > Another question: I see that the .suspend function is not used in the > > frontends anymore, but the structure still has that member. Is the suspend > > member about to be removed? > > The block and net drivers don''t need this at the moment, but it seems like > some driver may need it some time, so no, we won''t be removing it. It does no > harm to support it, and it may be useful to someone.Is there any driver in the tree that needs it? if not, the Linux way would be to remove it until such a driver makes it into the tree and then add it. It''s a very effective policy for keeping bloat at bay. Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Murillo Fernandes Bernardes
2005-Nov-18 16:47 UTC
Re: [Xen-devel] Driver Architecture Changes
On Thursday 17 November 2005 15:26, Ewan Mellor wrote:> On Wed, Nov 16, 2005 at 04:40:34PM -0500, Stefan Berger wrote: > > Hello Ewan, > > > > I am following the changes with the TPM driver pair. I was wondering > > what causes the ''add'' action to be invoked on the hotplug scripts and why > > would one not see a remove action if a previous ''add'' action was > > encountered and it had finished successfully. >I am looking network drivers. Hotplug scripts expects the offline action too, but that does not occur. Is that correct? All other actions (add, online, remove) are ok. If offline is not needed anymore I think we should remove that from hotplug scripts. I can do that. -- Murillo Fernandes Bernardes _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Nov 18, 2005 at 02:47:59PM -0200, Murillo Fernandes Bernardes wrote:> On Thursday 17 November 2005 15:26, Ewan Mellor wrote: > > On Wed, Nov 16, 2005 at 04:40:34PM -0500, Stefan Berger wrote: > > > Hello Ewan, > > > > > > I am following the changes with the TPM driver pair. I was wondering > > > what causes the ''add'' action to be invoked on the hotplug scripts and why > > > would one not see a remove action if a previous ''add'' action was > > > encountered and it had finished successfully. > > > > I am looking network drivers. Hotplug scripts expects the offline action too, > but that does not occur. Is that correct?No, that''s not correct. If we''re losing the offline event, then that''s a bug. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
xen-devel-bounces@lists.xensource.com wrote on 11/18/2005 03:10:55 AM:> On Thu, Nov 17, 2005 at 09:37:37PM +0000, Ewan Mellor wrote: > > On Thu, Nov 17, 2005 at 02:51:38PM -0500, Stefan Berger wrote: > > > > > Another question: I see that the .suspend function is not used inthe> > > frontends anymore, but the structure still has that member. Is thesuspend> > > member about to be removed? > > > > The block and net drivers don''t need this at the moment, but it seemslike> > some driver may need it some time, so no, we won''t be removing it.Itdoes no> > harm to support it, and it may be useful to someone. > > Is there any driver in the tree that needs it? if not, the Linux way > would be to remove it until such a driver makes it into the tree and > then add it. It''s a very effective policy for keeping bloat at bay.The TPM driver does need it. I was wondering about the future of the method since the network and block device drivers had used it before. Cheers, Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel