--- Day changed

--- Log opened Wed Apr 27 23:59:02 2005
00:13 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
02:24 -!- DEac- [~deac@xdsl-81-173-162-125.netcologne.de] has quit [Quit: Verlassend]
02:25 -!- DEac- [~deac@xdsl-81-173-162-125.netcologne.de] has joined #xen
02:29 -!- sleon [test@e180056038.adsl.alicedsl.de] has joined #xen
02:29 < sleon> hi
02:29 < sleon> which python twisted plugins do i need ?
02:38 < sleon> i mean i do: xend start
02:38 < sleon> and it won't start!!
02:41 < sleon> S.O.S
03:13 -!- sleon [test@e180056038.adsl.alicedsl.de] has quit [Quit: Leaving]
03:31 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
04:12 -!- sleon [~sleon@129.69.221.149] has joined #xen
04:12 < sleon> hi
04:12 < sleon> i have xen 2.0.5 built from source
04:12 < sleon> xend starts but then xm list complains that connection was refused
04:12 < sleon> what is the cause for it?
04:47 -!- anticw [cw@adsl-67-124-119-21.dsl.snfc21.pacbell.net] has joined #xen
04:47 -!- mode/#xen [+o anticw] by ChanServ
04:47 -!- mode/#xen [+o cf0989b8] by anticw
04:50 -!- athomas [~athomas@ppp-0-91.lond-a-3.access.uk.tiscali.com] has joined #xen
05:00 < sleon> hallo
05:00 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
05:00 < sleon> i have a problem
05:00 < sleon> when i start xend start
05:00 < sleon> and then do xm list
05:00 < sleon> i get : connection refused
05:01 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has quit [Remote host closed the connection]
05:02 -!- hebutterworth [~harry@blueice1n1.de.ibm.com] has quit [Quit: Leaving]
05:05 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
05:15 -!- sleon [~sleon@129.69.221.149] has quit [Remote host closed the connection]
05:22 -!- sleon [~sleon@129.69.221.149] has joined #xen
05:22 < sleon> hi
05:22 < sleon> i can not start xend 
05:22 < sleon> heeeeeeeeeeeeeeeeeelp
05:41 < sleon> hallloo
06:01 -!- nextime [~nextime@213-140-6-96.fastres.net] has quit [Quit: nextime has no reason]
06:02 < sleon> HELP HELP HELp
06:07 -!- nextime [~nextime@213-140-6-96.fastres.net] has joined #xen
06:09 < sleon> nextime, help me
06:09 < sleon> nextime, i do: xend start
06:09 < sleon> no error is reported
06:09 < sleon> then i do : xm list
06:09 < sleon> i get connection 111 refused
06:09 < sleon> (is xend running)
06:09 < sleon> so i start it, but it won't start
06:16 -!- sleon [~sleon@129.69.221.149] has left #xen [Verlassend]
06:29 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Quit: Leaving]
06:35 -!- DEac- [~deac@xdsl-81-173-162-125.netcologne.de] has quit [Ping timeout: 480 seconds]
06:48 -!- DEac- [~deac@xdsl-84-44-145-3.netcologne.de] has joined #xen
07:59 -!- visik7 [~ciao@host55-41.pool80182.interbusiness.it] has joined #xen
08:22 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
09:05 -!- hebutterworth [~harry@blueice4n1.de.ibm.com] has joined #xen
09:19 -!- athomas [~athomas@ppp-0-91.lond-a-3.access.uk.tiscali.com] has quit [Quit: Leaving]
09:22 -!- hebutterworth [~harry@blueice4n1.de.ibm.com] has quit [Read error: Operation timed out]
09:22 -!- hebutterworth [~harry@blueice1n1.uk.ibm.com] has joined #xen
09:23 -!- knewt [~jmb@p213.54.76.1.tisdip.tiscali.de] has quit [Ping timeout: 480 seconds]
09:25 -!- hebutterworth [~harry@blueice1n1.uk.ibm.com] has quit [Remote host closed the connection]
09:27 -!- knewt [~jmb@p213.54.76.1.tisdip.tiscali.de] has joined #xen
09:39 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Quit: Leaving]
09:40 -!- unriel is now known as riel
09:40 < riel> ok, time to make memory ballooning work the way it was meant to ;)
09:55 -!- athomas [~athomas@ppp-0-250.lond-a-1.access.uk.tiscali.com] has joined #xen
10:05 -!- rh_out is now known as rharper
10:49 -!- muli [~muli@alhambra.mulix.org] has quit [Ping timeout: 480 seconds]
10:59 -!- jon-out is now known as jonmason
11:00 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has quit [Remote host closed the connection]
11:19 -!- visik7 [~ciao@host55-41.pool80182.interbusiness.it] has quit [Remote host closed the connection]
11:21 -!- knewt_ [~jmb@p213.54.96.138.tisdip.tiscali.de] has joined #xen
11:25 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
11:25 -!- knewt [~jmb@p213.54.76.1.tisdip.tiscali.de] has quit [Read error: Connection reset by peer]
11:38 -!- cfreak [cfreak@dsl-084-056-100-138.arcor-ip.net] has joined #xen
11:41 -!- knewt_ is now known as knewt
11:41 < knewt> anyone know if there's likely to be a difference in speed in C between "num >> shift << shift" or "num & ~(size-1)"?
11:46 < rharper> not sure, but I recognize &~ more easily than >> shift << , then again, I dont do a lot of bitshifting
11:49 < jonmason> knewt: I've had people argue with me that <</>> is easier to read
11:50 < jonmason> I would think the perf would be roughly equilivant
11:52 < knewt> well, quick test on a 50,000x50,000 loop gives 18.5s for the 1st and 17s for the 2nd. probably not worth worrying about then
11:53 < knewt> so i think i'll go for the 1st, as it's easier for me to see what it's doing at a glance
12:13 -!- hebutterworth [~harry@blueice4n1.uk.ibm.com] has joined #xen
12:14 -!- matta-lt [~matta@69.93.28.254] has joined #xen
12:23 -!- MarkWilliamson [~MarkW@maw48.kings.cam.ac.uk] has joined #xen
12:26 -!- edsuom [~edsuom@207-118-65-127.dyn.centurytel.net] has joined #xen
12:26 -!- strafbomber [~admin@gw-ha1.gw.hosteurope.de] has joined #xen
12:26 < strafbomber> hello
12:27 < hebutterworth> hey, MarkWilliamson, am currently trying to hook my back-end to my front-end through my new xend usb code.
12:28 < hebutterworth> Can unload and load driver modules OK if I limit functionality to just driver status messages.
12:28 < strafbomber> i´m using xen on a suse 9.3 machine, in a xen console i get the following error message "Couldnt get a file descriptor referring to the console", what can i do? i think i have to adjust something in my inittab, right?
12:28 < strafbomber> (sorry for bad english)
12:29 < hebutterworth> But if I send a be_create message for a USB device as a result of receiving a be driver status up message the console locks up for all domains.
12:30 < hebutterworth> Any idea what would cause everything to lock up like that.  Looks like some kind of deadlock in xend to me.
12:30 < MarkWilliamson> hebutterworth: great news!
12:30 < MarkWilliamson> good timing as well, 2.4 dom0 doesn't have long to live ;-)
12:30 < MarkWilliamson> (in the unstable tree, that is)
12:31 < hebutterworth> Well, there is still much work to do and progress is very slow.
12:31 < MarkWilliamson> after the consoles lock up, does Xend respond to anything?
12:31 < hebutterworth> I can do an xm destroy on the domains
12:31 < MarkWilliamson> oooh, that's a bit weird.
12:32 < MarkWilliamson> anything interesting in xend's logs
12:32 < hebutterworth> Nothing in the log.
12:32 < hebutterworth> I have my driver doing printfs
12:32 < hebutterworth> If I disable the be_create message
12:33 < hebutterworth> then the back-end sends the driver status up message
12:33 < hebutterworth> which is received by xend which pretends to send the be_create
12:33 < hebutterworth> then I can unload the back end driver module
12:33 < hebutterworth> but if I try to enable the be create message
12:34 < hebutterworth> then the back end driver hangs halfway through sending the be driver status up
12:34 < hebutterworth> and xend never sees a response to the be_create
12:34 < MarkWilliamson> ok that's quite weird
12:35 < MarkWilliamson> what era Xend is this - when did you pull it?
12:35 < hebutterworth> Maybe a week before the xen summit
12:35 < MarkWilliamson> Well it shouldn't be strictly a deadlock because that Xend is lock free (that's going to change)
12:36 < hebutterworth> I thought that trying to send the be_create before responding to the driver status up might be an issue. What do you think?
12:37 < MarkWilliamson> hmmmm.  could be upsetting the state machine in the backend I suppose.  seems suprising if it is, tho.
12:38 < hebutterworth> No, the state machine in the backend can cope with it.  I had to write new state machines to cope with shutdown for unloading the modules.
12:38 < hebutterworth> Having unloadable modules was supposed to save me debug time.
12:39 < MarkWilliamson> yeah
12:39 < MarkWilliamson> can you put some tracing in the backend drivers "control.c" to see what messages it thinks it's getting?
12:40 < hebutterworth> It already has printfs, the backend doesn't see any control messages: the be create never arrives.
12:40 < hebutterworth> At least, the console never shows that it arrives.
12:40 < hebutterworth> Also, it dosn't get into the kern.log.
12:40 < hebutterworth> So it probably really hasn't arrived.
12:41 < hebutterworth> But I also trace trying to send it in xend.
12:41 < MarkWilliamson> hmmmm.  it's strange because the control rings AFAIK can cope with out of order messages.
12:41 < hebutterworth> So my best guess was that I try to send it but xend won't send it until after sending the response to the driver status up.
12:41 < hebutterworth> And the response for that won't get sent until after I send the be_create.
12:42 < hebutterworth> But that was just a wild guess.
12:42 < MarkWilliamson> maybe some sort of ordering is being enfornced...
12:42 < MarkWilliamson> it's a bit difficult to tell with divergent code bases
12:42 < hebutterworth> I've not changed anything much outside the usb code.
12:43 < MarkWilliamson> I can't think of any obvious reason why the generic code in Xend or the kernel would choke on this
12:43 < hebutterworth> What's the status of the xend rewrite in Cambridge?
12:43 < MarkWilliamson> Although it's possible your mods are tickling a latent "feature"
12:44 -!- muli [~muli@alhambra.mulix.org] has joined #xen
12:45 < MarkWilliamson> Mike wray has rewritten the core Xend stuff to ditch Twisted and use language level threads
12:45 < hebutterworth> I can restrict the function in the back-end driver to eliminate the new code there from the equation. Maybe I can get the messages working that way.
12:45 < MarkWilliamson> The class hierarchy is flattened out so it's easier to follow the structure and control flow.
12:45 < MarkWilliamson> So basically, expect a "Xend++" in the unstable tree soonish, if it's not there already.
12:45 < hebutterworth> Still python?
12:46 < MarkWilliamson> This is a separate stream to the registry and modular tools.
12:46 < MarkWilliamson> Yes, it's the same codebase just spruced up and robustified.  It'll form the basis of the 3.0 tools.  The full rewrite will probably come later.
12:47 < hebutterworth> Is there any public documentation of these efforts that I can keep an eye on? Wiki pages for example?
12:48 < hebutterworth> There hasn't been any discussion on xen-devel for a while.
12:48 < MarkWilliamson> Errrm not much, no.
12:49 < MarkWilliamson> under the developer todo list there's quite a good overview of what's going on (you may like to add yourself although the page might be locked right nov)
12:49 < MarkWilliamson> but it's rather sparse on detail
12:49 < hebutterworth> OK.
12:56 -!- athomas [~athomas@ppp-0-250.lond-a-1.access.uk.tiscali.com] has quit [Quit: Leaving]
12:57 < riel> python is fine, once twisted is gone it should all be readable again
12:59 -!- strafbomber [~admin@gw-ha1.gw.hosteurope.de] has quit [Ping timeout: 480 seconds]
12:59 < MarkWilliamson> riel: the new code seems a bit easier to get into and hack on
12:59 < MarkWilliamson> so hopefully it'll enable the knowledge to be spread a bit more
13:00 < hebutterworth> I didn't find twisted a big deal.  I've had more difficulty trying to reverse engineer the intention of the control messages w.r.t driver module unload.
13:00 < hebutterworth> Came to the conclusion that be driver status down meant that the be had already freed up the fe resources
13:01 < hebutterworth> but fe driver status down was a request from the fe to get xend to free up the fe resources.
13:01 < hebutterworth> These assumptions seem to make it possible to construct state machines driven by the existing messages that allow driver module unload.
13:01  * riel is trying to find the place where variables get replaced for %d in the config file ;)
13:01 < riel> extra = "4 VMID=%d usr=/dev/sda6 mem=%dM" % vmid maxmem
13:02 < riel> that breaks, it appears currently only one variable can be replaced ;)
13:03 < hebutterworth> Thanks for your help, Mark, will try stripping down the back end to eliminate it as a cause of the problem.
13:04 < knewt> riel: ... % (vmid, maxmem)
13:04 < riel> knewt: ohhhhh
13:04 < riel> nope, still complaining
13:04 < riel>   File "/usr/lib/python2.4/site-packages/xen/xm/opts.py", line 418, in load
13:04 < riel>     execfile(defconfig, globals, locals)
13:04 < riel>   File "/etc/xen/two", line 116
13:04 < riel>     extra = "4 VMID=%d usr=/dev/sda6 mem=%dM" % (vmid maxmem)
13:04 < riel>                                                            ^
13:04 < riel> SyntaxError: invalid syntax
13:05 < knewt> you missed the comma
13:05 -!- strafbomber [~admin@gw-ha1.gw.hosteurope.de] has joined #xen
13:05 < riel>   File "/etc/xen/two", line 24, in vmid_check
13:05 < riel>     val = int(val)
13:05 < riel> TypeError: int() argument must be a string or a number
13:05 < riel> ;)
13:05 < matta-lt> riel: did the fixed xen rpm happen to get into last nights build?
13:05 -!- dash [~washort@adsl-159-172-100.bhm.bellsouth.net] has joined #xen
13:05 < riel> matta-lt: yes, fixed kernel-xen*
13:05 < matta-lt> ok
13:05 -!- knewt [~jmb@p213.54.96.138.tisdip.tiscali.de] has quit [Quit: frickin' reboot]
13:06 < matta-lt> 27-Apr-2005 15:22  14M 
13:06 < matta-lt> got it
13:07 < MarkWilliamson> riel: the config files are Python scripts - could can do *anything* in them (muhahahaha)
13:07 < riel> oh, so they're _run_ and not parsed ?
13:08 < riel> that would explain why I can't find parsing code ;)
13:08 < dash> yep
13:08 < riel> ok thanks for that hint ;)
13:08 < dash> it's usually a good strategy for config files, at least that way you don't have to guess about quoting rules :)
13:08 < riel> (this is how you can tell I spend too much time in the kernel)
13:13 < riel> doh!
13:14  * riel was being stupid and forget to set the vmid variable ;)
13:14 < riel> this was xmexample2 
13:14 < MarkWilliamson> riel: I've done that too
13:15 < MarkWilliamson> yes, they're executed but it happens in a little sandbox to avoid variable name clashes.  any syntax you can use in python (regexps, substitutions, etc.) should work, if you want to make your config files really nasty :-)
13:17 < Tv> also, configvar = file(".../config/var").read() is ok, if you don't like the python :)
13:17 < Tv> that's the _best_ part of programmable configuration
13:18 -!- admin_ [~admin@gw-ha1.gw.hosteurope.de] has joined #xen
13:19 -!- strafbomber [~admin@gw-ha1.gw.hosteurope.de] has quit [Read error: No route to host]
13:24 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
13:27 -!- admin_ [~admin@gw-ha1.gw.hosteurope.de] has quit [Quit: Verlassend]
13:29 -!- the_hydra [~a_mulyadi@202.147.200.25] has joined #xen
13:30 < edsuom> Newbie here: Is it realistic to think I could move my existing Gentoo 2.installation to run as a guest OS on a new system?
13:31 < edsuom> One potential problem is it's all Athlon XP optimized, and new system will be Opteron.
13:35 < edsuom> No reply? Doesn't sound promising.
13:35 < hollis> I think it's realistic, but I haven't done it so I don't know
13:36 < matta-lt> edsuom: athlon and opteron use the same optimization flags for gcc so it should be fine
13:36 < the_hydra> edsuom: newbie to newbie-- have u check the Xen wiki?
13:36  * edsuom blushes
13:37 -!- knewt [~jmb@p213.54.96.138.tisdip.tiscali.de] has joined #xen
13:37 < matta-lt> the problem would be if you moved to a p4 arch system...
13:38 < edsuom> Thanks.
13:39 -!- edsuom [~edsuom@207-118-65-127.dyn.centurytel.net] has quit [Remote host closed the connection]
13:42 -!- hebutterworth [~harry@blueice4n1.uk.ibm.com] has quit [Quit: Leaving]
13:44 -!- the_hydra [~a_mulyadi@202.147.200.25] has quit [Quit: ]
14:12 -!- mael [~mael@nat.inha.fr] has quit [Ping timeout: 480 seconds]
14:20 -!- MarkWilliamson [~MarkW@maw48.kings.cam.ac.uk] has quit [Ping timeout: 480 seconds]
14:24 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
14:41 -!- mael [~mael@nat.inha.fr] has joined #xen
14:43 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
14:43 -!- nextime [~nextime@213-140-6-96.fastres.net] has quit [Ping timeout: 480 seconds]
14:57 -!- DEac- [~deac@xdsl-84-44-145-3.netcologne.de] has quit [Quit: Verlassend]
15:04 -!- DEac- [~deac@xdsl-81-173-163-107.netcologne.de] has joined #xen
15:12 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
15:15 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has quit [Remote host closed the connection]
15:27 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
15:46 < matta-lt> riel: new fedora en build doesn't work too well... gets to booting, and then
15:46 < matta-lt> slab sgpool-8: redzone mismatch in slabp c7f08000, objp c7f086e0, bufctl 0xfffe
15:46 < matta-lt> Redzone: 0x0/0x170fc2a5.
15:46 < matta-lt> Last user: [<c014cdb5>](mempool_create+0xe5/0x110)
15:46 < matta-lt> 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
15:46 < matta-lt> 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
15:47 < matta-lt> ------------[ cut here ]------------
15:47 < matta-lt> kernel BUG at drivers/xen/netback/netback.c:101!
15:47 < matta-lt> invalid operand: 0000 [#1]
15:47 < matta-lt> a few pages of OOPS data
15:50 < riel> matta-lt: which kernel and xen version ?
15:50 < riel> you need xen-2-20050423 for kernel 1275
15:51 < matta-lt> yep
15:51 < matta-lt> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/xen-2-20050424.i386.rpm
15:51 < matta-lt> that's 0424...
15:51 < riel> oh right, 23 was my test build here
15:51 < riel> 24 is the exact same sources, built in the build system
15:51 < matta-lt> do you want me to e-mail you what I have?
15:52 < riel> I'll try it here ;)
15:53 -!- cfreak [cfreak@dsl-084-056-100-138.arcor-ip.net] has quit [Quit: .]
15:54 < riel> on what kind of system are you trying it ?
15:54 < riel> it's starting up fine here
15:55 < riel> if you open a bug, please open it on bugzilla.xensource.com
15:55 < riel> if it turns out to be fedora specific, I'll just assign it to myself ;)
16:04 < matta-lt> riel: opteron
16:05 < riel> running it on a xeon here - no problem
16:07 -!- hebutterworth [~harry@blueice2n1.uk.ibm.com] has joined #xen
16:09  * riel wonders about paravirtualised xen on PPC ...
16:10  * aliguori thinks riel should poke hollis on that one
16:10 < aliguori> :-)
16:10 < riel> yeah, I guess I should ;)
16:11 < hollis> yeah, that's the idea...
16:12 < hollis> although at least for now we would like to fit into the pSeries hypervisor ABI; i.e. no PPC Linux patches needed
16:12 -!- hebutterworth [~harry@blueice2n1.uk.ibm.com] has quit [Quit: Leaving]
16:18 < riel> *nod*
16:24 < aliguori> hollis: are you guys gonna implement xen-style drivers for ppc after the initial papr drivers?
16:25 < aliguori> hollis: is it possible to get xen running on the g5s (after modifying the kernel of course)?
16:47 < hollis> the current Apple G5s have hypervisor mode disabled, which is unfortunate
16:47 < aliguori> hollis: but you could still paravirtualize them right?
16:47 < hollis> mostrows is working on a hypervisor model for non-hypervisor-enabled PPC, but that will have a radically different interface from the pSeries model
16:47 < knewt> an individual work_struct only ever runs once at any particular moment in time, right?
16:48 < aliguori> hollis: ahh
16:48 < hollis> aliguori: so for that mode, I assume there wouldn't be any problem using the Xen drivers (assuming they don't need much work)
16:48 < hollis> aliguori: since the kernel needs to be all hacked up anyways
16:48 < aliguori> hollis: how much work do you think it would be?
16:49 < aliguori> hollis: wrt to the linux port
16:49 < hollis> I haven't heard anything from mostrows recently, but I think it will be significant
16:49 < hollis> pushing the kernel into user mode is no small thing
16:50 < aliguori> hm, so i shouldn't buy an apple machine anytime soon then :-)
16:50 < hollis> x86 has the whole ring distinction, which gives you a little wiggle room for a hypervisor
16:50 < riel> on PPC you have the segments
16:50 < hollis> yeah. we hope that one day Apple will stop disabling hypervisor mode in their systems, but...
16:50 < riel> those might be useful
16:51 < hollis> riel: yes, they're better than nothing ;) but that doesn't address privileged instructions, only memory protection
16:51 < knewt> hollis: they probably will at some point, but charge a lot more for them *g*
16:54 < riel> knewt: didn't apple start the "charge a lot more" thing already ? ;)
16:54 < knewt> riel: any idea about my work_struct question above?
16:54 < riel> knewt: sorry, nope
16:58 -!- hebutterworth [~harry@blueice4n1.uk.ibm.com] has joined #xen
16:59 < hebutterworth> I just spent a whole day debugging a problem that turned out to be an error in whitespace in the usb xend code I wrote.
16:59 < hollis> ouch. been there... :)
16:59 < aliguori> hehe.. mmm, python
16:59 < knewt> ouch. that's where whitespace-sensitive languages get annoying
16:59 < hollis> actually I've been there with C and braces
17:00 < hebutterworth> So, I was calling packMsg, which takes a lot of parameters
17:00 < hollis> the whitespace was correct, but the braces were imaginary ;)
17:00 < hebutterworth> and I was putting the parameters below...
17:00 < hebutterworth> (
17:00 < hebutterworth>     ...
17:00 < hebutterworth> )
17:01 < hebutterworth> Seemd ok to me with only 3 days python experience
17:01 < hebutterworth> Executed
17:01 < hebutterworth> failed silently
17:01 < hebutterworth> by hanging messages
17:01 < hebutterworth> I want to take the person that made whitespace significant
17:02 < hebutterworth> and apply a hot poker
17:03 < Robot101> I know so many people who've suggested fixing python by adding braces back
17:03 < rharper> mm packMsg , I know that was my favorite part of xend 
17:04 < hollis> hebutterworth: well like I said above, you can make whitespace mistakes in C too, just in the other direction :)
17:04 < hebutterworth> So, I format parameters like that in C specifically because you can align matching parentheses either horizontally or vertically which means you never get them mixed up
17:06 < hebutterworth> seems I'll need to use ugly toothbrush layout or an explicit line continuation in python
17:12 < yosh> how were you trying to format things exactly?
17:13 < yosh> () should do implict line continutation
17:13 -!- visik7 [~ciao@host55-41.pool80182.interbusiness.it] has joined #xen
17:13 < hebutterworth> as above, with the parentheses on their own line
17:13 < hebutterworth> the problem was that I put the open parenthesis at the start of the next line
17:13 < yosh> oh
17:13 < yosh> that'd do it, yeah
17:14 < yosh> if you put the open parenthesis on the same line, it'd have been ok
17:14 < hebutterworth> yes, that's what fixed it.
17:14 < yosh> ok, I didn't know what you meant by "toothbrush layout"
17:15 < hebutterworth> toothbrush is what you get when all the parameters are at the end of a line
17:15 < hebutterworth> under each other
17:15 < hebutterworth> looks like a toothbrush. difficult to maintain
17:15 < hebutterworth> like this...
17:15 < hebutterworth> function_name(
17:16 < hebutterworth>                 
17:16 < hebutterworth>                      param,
17:16 < hebutterworth>                                   param,
17:16 < hebutterworth> oops
17:16 < hebutterworth> try again
17:16 < hebutterworth> function_name(
17:16 < hebutterworth>               param,
17:16 < hebutterworth>                 param,
17:16 < hebutterworth>               param,
17:16 < hebutterworth>              param)
17:17 < hebutterworth> sort of.  Anyway, very ugly.
17:17 -!- nextime [~nextime@213-140-6-96.fastres.net] has joined #xen
17:19 < hebutterworth> I've calmed down enough to drive home now :-)  Calling it a day.
17:19 -!- hebutterworth [~harry@blueice4n1.uk.ibm.com] has quit [Quit: Leaving]
17:20 < knewt> hmm. if there's only ever one work_struct running at a time in a workqueue, i wonder if there's any point /not/ creating it as single-threaded
17:24 -!- anticw is now known as cw
17:24 < cw> did anyone decide when/if the xensource were going to drop bk?
17:26 < Robot101> darcs is the one true way
17:26 < demon> does anyone have any suggestions on where I'd need to add code to in xend to handle an extra argument for a different network setup script? I want to have the ability to auto-bridge a Xen domain's network device to a specific VLAN, but I've been foiled previously trying to dig through the xend code
17:28 < hollis> cw: it makes sense to me to stay with bk until git becomes more usuable/better understood...
17:29 < cw> yeah, i just wanna rm bk here :)
17:29 < hollis> there are nightly snapshots, no? :)
17:30  * knewt was glad when the sfioball/etc stuff was given out by lm, as i /definitely/ shouldn't have been using bitkeeper
17:30 < aliguori> demon: the bridge code is all a script--not actually in xend
17:30 < aliguori> demon: look in /etc/xen/scripts/
17:31 < demon> aliguori: I know where it is
17:31 < demon> but I need to be able to add handling in xend for an argument
17:31 < demon> the shell script isn't the problem
17:32 < demon> it's that I'm rather unfamiliar with python
17:32 < rharper> demon: if you are modifying xm interface, you will want to see tools/python/xen/xm/main.py 
17:32 < rharper> thats the top 
17:33 < rharper> it gets a bit ugly after that, creating new "ops" that the xend server handles by calling other handlers
17:34 < cw> hollis: are there? of unstable?
17:36 < rharper> cw: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable-src.tgz 
17:36 < rharper> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html
17:36 < rharper> for testing as well 
17:37 < knewt> demon: you need to start with "preprocess_vifs" and "configure_vifs" in xen/xm/create.py, then you need to edit "configure", "reconfigure", "sxpr", and "vifctl_params" in xen/xend/server/netif.py, along with creating your own method def for your extra argument. and finally you need to edit "vifctl" in xen/xend/Vifctl.py
17:38 < demon> knewt: ahh... nice
17:38 < demon> that's what I needed
17:39 < demon> I'm actually writing my own code (in PHP... yeah, I know) to act as a client to xend
17:39 < demon> because I'm trying to get everything integrated so I can have a pretty management frontend
17:39 < demon> but that's just the info I was looking for :)
18:05  * caker tests vm-tools-0.0.9a
18:06 < hollis> aliguori: don't forget to include a brief description of vm-tools in your announce mails, for people who haven't been following along...
18:07 -!- riel is now known as unriel
18:09 < caker> aliguori: vm-tools won't build against -testing unless you remove the last arg from tools/vm-build-linux.c:
18:09 < caker> ret = xc_linux_build(xc_handle, domid, kernel,
18:09 < caker>          ramdisk, cmdline, evtchn, flags, 1);
18:10 < visik7> how can I assign 2 mac address to a single interface so I can obtain 2 dhcp ip with 1 ethernet ?
18:11 < aliguori> caker: oops, yeah, that's a mistake
18:11 < aliguori> hollis: ok, thanks
18:12 < knewt> visik7: err, you can only have 1 mac address per network interface
18:13 < visik7> knewt I know but I'm able to have multiple dhcp request with a single interface using bridging module one for the bridged iface and one for a xen machine
18:14 < visik7> do it's not possible to have a multiple mac address card without run a xen domu ?
18:16 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Quit: Client exiting]
18:20 < knewt> visik7: surely the easiest way if you need more than one ip assigned over dhcp is to tell the dhcp client to request more than one, and configure the server appropriately?
18:21 < visik7> the server is not under my control and if see that I'm requesting 2 ip from the same mac address it lock me
18:21 < visik7> locks
18:21 < visik7> someone tell me to use vconfig
18:21 < visik7> but I dunno how to
18:21 < demon> er... vconfig is for setting up VLANs
18:22 < demon> which I don't think is going to help you
18:22 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Read error: Operation timed out]
18:22 < demon> I don't think most NICs support multiple MAC addresses assigned to one card... you might be able to use bridging to do something
18:22 < visik7> ok so I've solved creating a vpn in loopback so tap0 and tap1 bridging tap0 with eth0 and assign 2 different mac addresses one to br0 and the other to tap1
18:23 < visik7> but it sucks
18:23 < visik7> and really doesn't work in loopback but only if tap1 stay on another machine (dunno why)
18:24 < visik7> do u have other solution ?
18:51 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
18:52 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:53 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
19:06 -!- buggs [~noidentd@n80-237-228-135.cnet.hosteurope.de] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- cf0989b8 [~cf0989b8@ns.372broadway.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- mikegrb [~michael@mikegrb.netop.oftc.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- paavon [paavon@alpha.phnet.fi] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- eigood [~adam@brown.brainfood.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- demon [demon@newcastle.devrandom.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- yosh [~manish@graft.XCF.Berkeley.EDU] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- Dougie [~Doug@shade.idmf.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- plars [~plars@pixpat.austin.ibm.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- caker [~caker@ns.theshore.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- unriel [~riel@nat-pool-bos.redhat.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- DEac- [~deac@xdsl-81-173-163-107.netcologne.de] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- mael [~mael@nat.inha.fr] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- knewt [~jmb@p213.54.96.138.tisdip.tiscali.de] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- dash [~washort@adsl-159-172-100.bhm.bellsouth.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- matta-lt [~matta@69.93.28.254] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- sunny [sunny@opencurve.org] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- HoraPe [~horape@200.69.230.10] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- visik7 [~ciao@host55-41.pool80182.interbusiness.it] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- cw [cw@adsl-67-124-119-21.dsl.snfc21.pacbell.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- monrad [~monrad@213083190130.sonofon.dk] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- Tv [~Tv@hq.inoi.fi] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- Hunger [Hunger.hu@Hunger.hu] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- surriel [~riel@riel.netop.oftc.net] has quit [kinetic.oftc.net uranium.oftc.net]
19:06 -!- HoraPe [~horape@200.69.230.10] has joined #xen
19:06 -!- sunny [sunny@opencurve.org] has joined #xen
19:06 -!- matta-lt [~matta@69.93.28.254] has joined #xen
19:06 -!- dash [~washort@adsl-159-172-100.bhm.bellsouth.net] has joined #xen
19:06 -!- knewt [~jmb@p213.54.96.138.tisdip.tiscali.de] has joined #xen
19:06 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
19:06 -!- mael [~mael@nat.inha.fr] has joined #xen
19:06 -!- DEac- [~deac@xdsl-81-173-163-107.netcologne.de] has joined #xen
19:06 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
19:06 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
19:06 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
19:06 -!- Hunger [Hunger.hu@Hunger.hu] has joined #xen
19:06 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
19:06 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
19:06 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
19:06 -!- cw [cw@adsl-67-124-119-21.dsl.snfc21.pacbell.net] has joined #xen
19:06 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
19:06 -!- visik7 [~ciao@host55-41.pool80182.interbusiness.it] has joined #xen
19:06 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
19:06 -!- caker [~caker@ns.theshore.net] has joined #xen
19:06 -!- unriel [~riel@nat-pool-bos.redhat.com] has joined #xen
19:06 -!- plars [~plars@pixpat.austin.ibm.com] has joined #xen
19:06 -!- Dougie [~Doug@shade.idmf.net] has joined #xen
19:06 -!- yosh [~manish@graft.XCF.Berkeley.EDU] has joined #xen
19:06 -!- demon [demon@newcastle.devrandom.net] has joined #xen
19:06 -!- surriel [~riel@riel.netop.oftc.net] has joined #xen
19:06 -!- mikegrb [~michael@mikegrb.netop.oftc.net] has joined #xen
19:06 -!- buggs [~noidentd@n80-237-228-135.cnet.hosteurope.de] has joined #xen
19:06 -!- cf0989b8 [~cf0989b8@ns.372broadway.com] has joined #xen
19:06 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has joined #xen
19:06 -!- paavon [paavon@alpha.phnet.fi] has joined #xen
19:06 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has joined #xen
19:06 -!- eigood [~adam@brown.brainfood.com] has joined #xen
19:06 -!- mode/#xen [+oo cw Sir_Ahzz  ] by jupiter.oftc.net
19:14 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
19:15 -!- matta-lt [~matta@69.93.28.254] has quit [Quit: Remember the... the... uhh.....]
19:40 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
20:13 -!- jeroney [~jeroney@rrcs-24-173-101-48.sw.biz.rr.com] has joined #xen
20:16 -!- jeroney [~jeroney@rrcs-24-173-101-48.sw.biz.rr.com] has quit [Quit: ]
20:21 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
20:24 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:57 -!- surriel is now known as riel
21:06 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has quit [orion.oftc.net nova.oftc.net]
21:06 -!- DEac- [~deac@xdsl-81-173-163-107.netcologne.de] has quit [orion.oftc.net nova.oftc.net]
21:06 -!- mael [~mael@nat.inha.fr] has quit [orion.oftc.net nova.oftc.net]
21:06 -!- knewt [~jmb@p213.54.96.138.tisdip.tiscali.de] has quit [orion.oftc.net nova.oftc.net]
21:06 -!- dash [~washort@adsl-159-172-100.bhm.bellsouth.net] has quit [orion.oftc.net nova.oftc.net]
21:06 -!- HoraPe [~horape@200.69.230.10] has quit [orion.oftc.net nova.oftc.net]
21:06 -!- sunny [sunny@opencurve.org] has quit [orion.oftc.net nova.oftc.net]
21:06 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
21:06 -!- DEac- [~deac@xdsl-81-173-163-107.netcologne.de] has joined #xen
21:06 -!- mael [~mael@nat.inha.fr] has joined #xen
21:06 -!- knewt [~jmb@p213.54.96.138.tisdip.tiscali.de] has joined #xen
21:06 -!- dash [~washort@adsl-159-172-100.bhm.bellsouth.net] has joined #xen
21:06 -!- sunny [sunny@opencurve.org] has joined #xen
21:06 -!- HoraPe [~horape@200.69.230.10] has joined #xen
21:07 < riel> HoraPe !
21:07 < riel> nice to see you here
21:10 < HoraPe> hi rik
21:10 < HoraPe> thanks
21:31 < knewt> hmm. methinks that at 3:30am it might be a good idea to get some sleep and check over the spinlocks tomorrow, instead of just trying it out tonight
21:52 -!- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
21:52 -!- aliguori-- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
21:53 -!- aliguori-- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: ]
21:53 -!- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: ]
21:56 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Remote host closed the connection]
22:08 -!- John_K [m4levolent@blk-222-164-135.eastlink.ca] has joined #xen
22:09 < John_K> hello
22:34 -!- katzj [~katzj@c-66-30-206-55.hsd1.ma.comcast.net] has joined #xen
23:44 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Quit: Leaving]
--- Log closed Thu Apr 28 23:59:00 2005