# HG changeset patch
# User Hollis Blanchard <hollisb@us.ibm.com>
# Date 1158780052 18000
# Node ID f7d90f962967a5a94fce0c04f8fcac449f36344f
# Parent 041be3f6b38e05f904d240630c18cadb1259317b
[XEND] Remove hard tabs.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
diff -r 041be3f6b38e -r f7d90f962967 tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py Tue Sep 19 14:26:47 2006 +0100
+++ b/tools/python/xen/xend/XendDomainInfo.py Wed Sep 20 14:20:52 2006 -0500
@@ -1093,15 +1093,15 @@ class XendDomainInfo:
## public:
def destroyDevice(self, deviceClass, devid):
- if type(devid) is str:
- devicePath = ''%s/device/%s'' % (self.dompath,
deviceClass)
- for entry in xstransact.List(devicePath):
- backend = xstransact.Read(''%s/%s'' % (devicePath, entry),
"backend")
- devName = xstransact.Read(backend, "dev")
- if devName == devid:
- # We found the integer matching our devid, use it instead
- devid = entry
- break
+ if type(devid) is str:
+ devicePath = ''%s/device/%s'' % (self.dompath,
deviceClass)
+ for entry in xstransact.List(devicePath):
+ backend = xstransact.Read(''%s/%s'' % (devicePath,
entry), "backend")
+ devName = xstransact.Read(backend, "dev")
+ if devName == devid:
+ # We found the integer matching our devid, use it instead
+ devid = entry
+ break
return self.getDeviceController(deviceClass).destroyDevice(devid)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hollis Blanchard:> [XEND] Remove hard tabs.That''s stupid, tabs are a relief to use when coding compared to spaces.> - if type(devid) is str: > - devicePath = ''%s/device/%s'' % (self.dompath, deviceClass) > - for entry in xstransact.List(devicePath): > - backend = xstransact.Read(''%s/%s'' % (devicePath, entry), "backend") > - devName = xstransact.Read(backend, "dev")> + if type(devid) is str: > + devicePath = ''%s/device/%s'' % (self.dompath, deviceClass) > + for entry in xstransact.List(devicePath): > + backend = xstransact.Read(''%s/%s'' % (devicePath, entry), "backend") > + devName = xstransact.Read(backend, "dev")Seems to me like you''re breaking Python indentation rules now? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2006-09-21 at 07:58 +0200, Molle Bestefich wrote:> Hollis Blanchard: > > [XEND] Remove hard tabs. > > That''s stupid, tabs are a relief to use when coding compared to spaces.That''s a separate conversation.> > - if type(devid) is str: > > - devicePath = ''%s/device/%s'' % (self.dompath, deviceClass) > > - for entry in xstransact.List(devicePath): > > - backend = xstransact.Read(''%s/%s'' % (devicePath, entry), "backend") > > - devName = xstransact.Read(backend, "dev") > > > + if type(devid) is str: > > + devicePath = ''%s/device/%s'' % (self.dompath, deviceClass) > > + for entry in xstransact.List(devicePath): > > + backend = xstransact.Read(''%s/%s'' % (devicePath, entry), "backend") > > + devName = xstransact.Read(backend, "dev") > > Seems to me like you''re breaking Python indentation rules now?Hmm, that is a stupid mistake on my part... -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
MB> That''s stupid, tabs are a relief to use when coding compared to MB> spaces. To quote from the Python style guide[1]: "The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only." "spaces-only are strongly recommended over tabs." [1] http://www.python.org/dev/peps/pep-0008/ -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2006-09-20 at 14:21 -0500, Hollis Blanchard wrote:> # HG changeset patch > # User Hollis Blanchard <hollisb@us.ibm.com> > # Date 1158780052 18000 > # Node ID f7d90f962967a5a94fce0c04f8fcac449f36344f > # Parent 041be3f6b38e05f904d240630c18cadb1259317b > [XEND] Remove hard tabs. > Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>Thanks, I committed a similar patch but with the right indentation :) Cheers, Alastair _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hollis Blanchard wrote:> Molle Bestefich wrote: > > Hollis Blanchard: > > > [XEND] Remove hard tabs. > > > > That''s stupid, tabs are a relief to use when coding compared to spaces. > > That''s a separate conversation.Seemed relevant since what you''re doing is switching things originally coded one way to use what *you* prefer, without changing the code at all (right?). Dan Smith writes:> To quote from the Python style guide[1]: > > "The most popular way of indenting Python is with spaces only. > The second-most popular way is with tabs only."Where''s the statistics to document that? Why does that imply that coding with spaces is better in any way?> "spaces-only are strongly recommended over tabs."Obviously the guy who wrote that is a big dope.> > Seems to me like you''re breaking Python indentation rules now? > > Hmm, that is a stupid mistake on my part...Ok, thought so ;). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 2006-09-24 at 12:50 +0200, Molle Bestefich wrote:> Hollis Blanchard wrote: > > Molle Bestefich wrote: > > > Hollis Blanchard: > > > > [XEND] Remove hard tabs. > > > > > > That''s stupid, tabs are a relief to use when coding compared to spaces. > > > > That''s a separate conversation. > > Seemed relevant since what you''re doing is switching things originally > coded one way to use what *you* prefer, without changing the code at > all (right?).No, actually, I prefer tabs. :) However, there were ~10 lines in that file using tabs, with all the rest using spaces. In Python that''s a more serious offense than in other languages. -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, Sep 24, 2006 at 12:50:22PM +0200, Molle Bestefich wrote:> Hollis Blanchard wrote: > >Molle Bestefich wrote: > >> Hollis Blanchard: > >> > [XEND] Remove hard tabs. > >> > >> That''s stupid, tabs are a relief to use when coding compared to spaces. > > > >That''s a separate conversation. > > Seemed relevant since what you''re doing is switching things originally > coded one way to use what *you* prefer, without changing the code at > all (right?). > > Dan Smith writes: > >To quote from the Python style guide[1]: > > > > "The most popular way of indenting Python is with spaces only. > > The second-most popular way is with tabs only." > > Where''s the statistics to document that? > Why does that imply that coding with spaces is better in any way? > > > "spaces-only are strongly recommended over tabs." > > Obviously the guy who wrote that is a big dope.Author of that statement is Guido, author of Python. Not a much better place to get style comments then from the language author. ;) -Sean -- Sean Dague IBM Linux Technology Center email: japh@us.ibm.com Open Hypervisor Team alt: sldague@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hollis Blanchard wrote:> On Sun, 2006-09-24 at 12:50 +0200, Molle Bestefich wrote: > >> Hollis Blanchard wrote: >> >>> Molle Bestefich wrote: >>> >>>> Hollis Blanchard: >>>> >>>>> [XEND] Remove hard tabs. >>>>> >>>> That''s stupid, tabs are a relief to use when coding compared to spaces. >>>> >>> That''s a separate conversation. >>> >> Seemed relevant since what you''re doing is switching things originally >> coded one way to use what *you* prefer, without changing the code at >> all (right?). >> > > No, actually, I prefer tabs. :) However, there were ~10 lines in that > file using tabs, with all the rest using spaces. In Python that''s a more > serious offense than in other languages. >As it has been mentioned, whitespace is the right thing to do in python. It''s not a point of debate. Tab-width is interpreted as 8 in Python. This can lead to subtle bugs in code where people use text-editors with different width tabs. These are real bugs that have actually occurred in Xen before. There have been big patches in Xend to globally remove tabs. Any time the creep back in, they ought to be removed. For more info, see: http://docs.python.org/ref/indentation.html Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sean Dague wrote:>>> "spaces-only are strongly recommended over tabs." >> Obviously the guy who wrote that is a big dope. > > Author of that statement is Guido, author of Python. Not a much better > place to get style comments then from the language author. ;) >And this whole debate is exactly why I prefer Perl :P -- Steve _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I''ve been experimenting with para-virtualized drivers running in hvm linux guests and seeing, as do others, the significant performance benefit of the PV drivers of the FV drivers. I have also noticed that qemu has the ''-net'' option for emulating a nic, which the python code takes advantage of, but such an option does not exist for the emulation of an ide device. My testing of the the PV blk driver was first done by creating a second blk device in the ''disk='''' line of the config file. I could not use the PV driver for the first device because the guest''s ide driver lays claim on hda before the PV driver is loaded. In an attempt to get the guest to come up entirely on the PV drivers I modified qemu''s ide.c to make the emulated device incompatible with the native IDE driver. This allows the PV driver to create hda and the OS came up just fine. (I had also rebuilt the guest''s initrd to include and load the PV drivers, of course.) Having proved to myself that the guest can come up on PV drivers alone, I returned to the issue of qemu always creating the IDE device in the emulated PCI config space as opposed to the nic support which creates a PCI entry programmatically. I see that currently in the config one can indicate ''ioemu:'' as an attribute of the ''dev'' in the ''disk='' line. This attribute, however, is ignored in blkif.py and the IDE entry is created anyway. The ''vif='' line uses the token ''type='' to indicate that the nic device is emulated by qemu by setting the type equal to ''ioemu'', the default being that the quest''s LAN is supported by netback. The parsers for the ''disk='' line do not look for the ''type='' token. I wish to create for block a similar functionality for block devices as we have for nics. My guests will use the native FV nic drivers or the PV driver just by simply adding or removing the ''type=ioemu'' from the ''vif='' line. Adding ''type='' to ''disk='' will create appreciated consistency. Further I would like to propose the introduction of a ''xenbus'' type in addition to ''ioemu''. This is in an effort to be backwards compatible to 3.0.2 as without specifying the type the nic defaults to PV drivers but disk defaults to IDE emulation. Specifying either ''ioemu'' or ''xenbus'' creates a obvious and deterministic result. It also provides a convention for the possible introduction of other backends without disturbing existing VMs. With the introduction of the ''type='' for disk it follows that there must be some changes to the python code and a new command line option for qemu which would cause (or rather prevent) a PCI IDE entry when needed. I write this longish letter in hopes of some relevant feedback, and to know if work towards this end is already in progress. Regards, Ross Maxfield Novell, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
All, I have been running on a 8-way 32 GB ES7000 system. I am on the tip of the xen-unstable tree (changeset 11627). To test xen, I ran 4 DomUs 2 of them were 8-way, with 10 GB memory and 2 others were 4-way with 1 GB of memory. The DomUs come up, run kernbench and ltp and shutdown. After about 3 hours of running, I tried to do an xm list and the machine locked up. I could not ssh into the box, but I could ping it. I could get data from the serial machine. Leaving the machine untouched for a long time does not alleviate the problem. The 8-way DomUs had completed their tests at this point and the 4-way domUs had finished their kernbench tests and were running LTP. Has anyone else seen issues like this? How can I debug this problem? I have attached the before and after info from the serial machine. run queues, memory info, VM info etc. I discovered this problem when I was giving Ryan Harper''s NUMA patches a spin last week. Further investigation revealed that the issue was *not* with the NUMA patches, but occurs in the mainline xen-unstable kernel. Thanks Raj Xen Development Team Unisys Corp. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I have been running on a 8-way 32 GB ES7000 system. > I am on the tip of the xen-unstable tree (changeset 11627). > > To test xen, I ran 4 DomUs 2 of them were 8-way, with 10 GB memory and2> others were 4-way with 1 GB of memory. The DomUs come up, runkernbench> and ltp and shutdown. After about 3 hours of running, I tried to do an > xm list and the machine locked up.Hmm, this isn''t going to be fun to find. Dom0 is presumably suffering from some nasty lockup, Maybe its root device has gone away, or there''s been some locking issue. If you boot with the console over the serial line (and don''t start X for good measure), do you see any messages from the dom0 kernel when the lockup happens? Can you get magic sysrq to work either on serial or on the console? Would be great to see the task queues inside the kernel? (''t'' key, I think) Can you repro this with a dom0 booted with a single VCPU (max_cpus=1) ? This may give better performance anyhow, depending on workload. The other real PITA to setup but very interesting thing to do would be to rerun the whole experiment with a PAE hypervisor and PAE guests. Best, Ian> I could not ssh into the box, but I could ping it. I could get datafrom> the serial machine. Leaving the machine untouched for a long time does > not alleviate the problem. > > The 8-way DomUs had completed their tests at this point and the 4-way > domUs had finished their kernbench tests and were running LTP. > > Has anyone else seen issues like this? > How can I debug this problem? > > I have attached the before and after info from the serial machine. run > queues, memory info, VM info etc. > > I discovered this problem when I was giving Ryan Harper''s NUMA patchesa> spin last week. > Further investigation revealed that the issue was *not* with the NUMA > patches, but occurs in the mainline xen-unstable kernel. > > Thanks > Raj > Xen Development Team > Unisys Corp._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> My testing of the the PV blk driver was first done by creating a > second blk device in the ''disk='''' line of the config file. I could > not use the PV driver for the first device because the guest''s ide > driver lays claim on hda before the PV driver is loaded. In an > attempt to get the guest to come up entirely on the PV drivers I > modified qemu''s ide.c to make the emulated device incompatible with > the native IDE driver. This allows the PV driver to create hda and > the OS came up just fine. (I had also rebuilt the guest''s initrd to > include and load the PV drivers, of course.)And the bootloader coped with this without any objections? I suppose they''d mostly be using BIOS services, and I could well believe our BIOS doesn''t actually bother to check the PCI device ids before going at the IDE controller.> Having proved to myself that the guest can come up on PV drivers > alone, I returned to the issue of qemu always creating the IDE > device in the emulated PCI config space as opposed to the nic > support which creates a PCI entry programmatically. I see that > currently in the config one can indicate ''ioemu:'' as an attribute of > the ''dev'' in the ''disk='' line. This attribute, however, is ignored > in blkif.py and the IDE entry is created anyway. The ''vif='' line > uses the token ''type='' to indicate that the nic device is emulated > by qemu by setting the type equal to ''ioemu'', the default being that > the quest''s LAN is supported by netback. The parsers for the > ''disk='' line do not look for the ''type='' token.I don''t think there are any firm plans for how to handle this at the moment, and it''s certainly not going to happen for a little while 3.0.3 gets ready. There was a suggestion at one point of having both types of device present in every domain and then trying to unplug the ioemu ones if we find that we have PV drivers available, but it''s not obvious that we''d always be able to get in early enough in the boot process. Steven. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> As I look further into this, an over-arching question begins to > form. Originally, I had suggested that a ''type='' be added to the > ''disk'' line, like the net, to indicate the use of FV or PV drivers. > But now I''m wondering if a more global tag should be used to > indicate that all drivers are either FV or PV. Implementing the > original idea would be a more involved but create the opportunity > for one disk device to be supported by a FV driver and another by a > PV driver. The question is, why would anyone ever wish to have > mixed driver technology? With the PV drivers having such a profound > increase in performance and given that PV drivers are available for > the quest (and assuming if a a PV driver is available for one > technology, i.e. LAN or BLK, then it would be available for the > other) then why would someone use the FV driver? Thus the more > simple solution to have a single switch in the guest''s config file > indicating the mode for all devices, LAN or BLK.Well, it''s rather handy when you''re actually working on the PV drivers, since you can e.g. have an ioemu root device and test the block driver on some other filesystem. Plus, if at some point in the future we implement a PV framebuffer you''re likely to have some guest installs with BLK+LAN but not framebuffer, and so mixed mode would be useful there. Steven. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > [XEND] Remove hard tabs. > > That''s stupid, tabs are a relief to use when coding compared to spaces.The important thing is that we try to have only tabs, or only spaces. As far as I know, we''ve chosen the latter. The interaction between Python''s interpretation of tabs as 8 spaces, vs some indents actually being spaces, and some being a mixture of the two makes for very brittle code: it''s very easy to change code semantics by changing indentation. This gets especially hairy if (for instance) somebody has a text editor not set to display tabs as 8 spaces, and / or which uses auto-indenting. We could really add a test to the staging repository that scans every .py file and grumbles if any tabs have arrived. Cheers, Mark> > - if type(devid) is str: > > - devicePath = ''%s/device/%s'' % (self.dompath, deviceClass) > > - for entry in xstransact.List(devicePath): > > - backend = xstransact.Read(''%s/%s'' % (devicePath, entry), > > "backend") - devName = xstransact.Read(backend, "dev") > > > > + if type(devid) is str: > > + devicePath = ''%s/device/%s'' % (self.dompath, deviceClass) > > + for entry in xstransact.List(devicePath): > > + backend = xstransact.Read(''%s/%s'' % (devicePath, entry), > > "backend") + devName = xstransact.Read(backend, "dev") > > Seems to me like you''re breaking Python indentation rules now? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel