--- Day changed

--- Log opened Wed Jan 11 23:59:02 2006
23:59 < kmacy> aliguori: ping
00:00 < aliguori> kmacy, pong
00:00 < kmacy> dude
00:00 < aliguori> sweet
00:00 < kmacy> I never got a schedule for the summit
00:00 < aliguori> hehe
00:00 < aliguori> kmacy, i'll forward you a copy :-)
00:00 < kmacy> thanks
00:00 < aliguori> there list is majorly borked
00:00 < aliguori> kmacy, preferred addr?
00:01 < kmacy> kip.macy@gmail.com
00:01 < kmacy> shit
00:01 < kmacy> these are logged
00:01 < kmacy> and searchable
00:01 < kmacy> oh well
00:01 < aliguori> oops, sorry
00:01 < aliguori> you could email the dude who keeps them and ask to scrub
00:01 < kmacy> If I'd been smart I would've put kip dot macy at gmail dot com
00:01 < kmacy> LOL
00:01 < kmacy> anyhow
00:02 < kmacy> Evidently I've been scheduled for a port update
00:02 < aliguori> yeah
00:02 < aliguori> you are :-)
00:02 < kmacy> when was the schedule sent out, before or after my announcement?
00:02 < aliguori> tuesday at 3:30
00:02 < aliguori> 01/10
00:03 < kmacy> ok
00:03 < aliguori> so yesterday
00:03 < kmacy> ok
00:03 < aliguori> i never got the actual invite :-) i had to have it fwd'd
00:03 < kmacy> me neither
00:03 < aliguori> only like two people at ibm got the invite with registration link
00:03 < kmacy> I got the very first invite
00:03 < aliguori> so did i
00:03 < kmacy> but nothing after that
00:04 < aliguori> oh well
00:04 < aliguori> kmacy, when are you in town?
00:04 < kmacy> I have to say putting graphics and sound at the same time as SVM is retarded
00:04 < aliguori> yeah :-(
00:04 < kmacy> I'll have to have that fixed
00:05 < aliguori> b/c i really wanted to go to the svm one
00:05 < kmacy> they clearly target the same audience
00:05 < aliguori> good :-) i would appreciate it
00:05 < aliguori> indeed
00:05 < kmacy> PPC and IA64 are interesting 
00:05 < kmacy> but I can miss those happily
00:05 < aliguori> hollisb got a domU booting in ppc
00:06 < kmacy> I heard 
00:06 < kmacy> very cool
00:06 < aliguori> yeah, it's exciting :-)
00:08 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
00:10 -!- tab [~tab@darwin.snarc.org] has joined #xen
00:10 -!- tab_ [~tab@darwin.snarc.org] has quit [Read error: Connection reset by peer]
00:11 < aliguori> kmacy, they still haven't mentioned anything about where or when we're supposed to show up AFAIK
00:11 < kmacy> heh heh
00:14 < kmacy> I BCC'd you
00:14 < aliguori> cool, thanks
00:15 < kmacy> I address them as "Gentlemen", I meant it to be humorous
00:15 < kmacy> my wife thought it sounded haughty
00:16 < aliguori> :-)
00:16 < aliguori> I took it as humorous :-)
00:21 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
00:52 -!- muli [~muli@87.69.40.180.cable.012.net.il] has joined #xen
00:55 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has joined #xen
00:57 < kmacy> hah hah
00:57 < kmacy> aliguori have you looked at the balloon driver?
00:58 < kmacy> is the only reason for the balloon_alloc_empty_page_range to free up space in lowmem?
01:20 < kmacy> aliguori: ping
01:56 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
02:23 -!- johnlev is now known as movement
02:23 -!- movement is now known as johnlev
02:29 -!- Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has quit [Quit: foo]
02:36 -!- cfreak [cfOFTC@no.real-lif3.de] has joined #xen
02:55 -!- kmacy [~kmacy@c-67-164-28-190.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds]
03:11 -!- shaun [~Shaun@ip68-4-213-166.oc.oc.cox.net] has joined #xen
03:11 < shaun> anybody have a idea what this error means... http://pastebin.com/502098
03:11 < shaun> building xen 3.0.0 from source
03:11 < shaun> finished a make world, now trying to do a make install
03:25 -!- womble [~mpalmer@sponge.solutionsfirst.com.au] has quit [Quit: What's behind the round window...]
03:28 -!- sdog [~sdog@62.58.98.210] has joined #xen
03:45 -!- pvanhoof [~pvanhoof@mailhost.newtec.be] has joined #xen
04:10 -!- dme [~dme@host-84-9-60-139.bulldogdsl.com] has quit [Remote host closed the connection]
04:10 -!- dme [~dme@host-84-9-60-139.bulldogdsl.com] has joined #xen
04:25 -!- smashie [smashie@212.125.206.25] has quit [Ping timeout: 480 seconds]
04:34 -!- sdog [~sdog@62.58.98.210] has quit [Quit: Everything is a Fucking DNS Problem]
04:35 -!- sdog [~sdog@62.58.98.210] has joined #xen
05:03 -!- xterminus [nobody@00104bc8bd59.click-network.com] has quit [Read error: Connection reset by peer]
05:03 -!- xterminus [nobody@00104bc8bd59.click-network.com] has joined #xen
05:16 -!- Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
05:26 -!- athomas [~athomas@host86-136-8-246.range86-136.btcentralplus.com] has joined #xen
05:28 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
05:29 -!- pdx6_ [~ballew@screen.sublinear.net] has joined #xen
05:32 -!- tsi_ [~tsi@monkey.projectmayhem.org] has joined #xen
05:34 -!- tsi [~tsi@monkey.projectmayhem.org] has quit [Ping timeout: 480 seconds]
05:35 -!- pdx6 [~ballew@screen.sublinear.net] has quit [Ping timeout: 480 seconds]
05:40 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has quit [Ping timeout: 480 seconds]
05:41 -!- muli [~muli@87.69.40.180.cable.012.net.il] has quit [Ping timeout: 480 seconds]
05:41 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
05:43 -!- rusty [~rusty@ppp57-52.lns1.cbr1.internode.on.net] has joined #xen
05:48 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has joined #xen
05:58 -!- bernarde [~bernarde@c91fa098.cps.virtua.com.br] has joined #xen
05:58 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has quit [Ping timeout: 480 seconds]
06:01 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has joined #xen
07:07 -!- shaun [~Shaun@ip68-4-213-166.oc.oc.cox.net] has quit [Ping timeout: 480 seconds]
07:12 -!- muli [~muli@87.69.40.180.cable.012.net.il] has joined #xen
07:28 -!- Rami [~Rami@mvil2.bb.netvision.net.il] has joined #xen
07:30 -!- Rami [~Rami@mvil2.bb.netvision.net.il] has left #xen []
08:12 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
08:33 -!- rusty [~rusty@ppp57-52.lns1.cbr1.internode.on.net] has quit [Quit: Client exiting]
09:09 -!- Sting [~Sting@mvil2.bb.netvision.net.il] has joined #xen
09:10 < Sting> Maybe somebody with a little knowledge on migration can answer a question I have regarding migration of domains 
09:10 < Sting> ?
09:36 -!- toks [~toks@bi01p1.nc.us.ibm.com] has joined #xen
09:49 -!- Sting [~Sting@mvil2.bb.netvision.net.il] has quit [Quit: Leaving]
09:56 < sdog> sting: what about just asking ?
09:56 < sdog> oh he's gong already ..
09:57 -!- nags [~nags@202.144.95.244] has quit [Quit: Linux Desktop Testing Project - http://gnomebangalore.org/ldtp]
10:11 -!- dansmith [~dan@bi01p1.co.us.ibm.com] has joined #xen
10:12 -!- bernarde [~bernarde@c91fa098.cps.virtua.com.br] has quit [Remote host closed the connection]
10:14 -!- athomas [~athomas@host86-136-8-246.range86-136.btcentralplus.com] has quit [Quit: Leaving]
10:20 < hikenboot> shaun: did you install    * GCC (preferably v3.2.x or v3.3.x; older versions are unsupported)
10:20 < hikenboot>     * GNU Make
10:20 < hikenboot>     * GNU Binutils
10:20 < hikenboot>     * Development install of zlib (e.g., zlib-dev)
10:20 < hikenboot>     * Development install of Python v2.3 or later (e.g., python-dev)
10:20 < hikenboot>     * bridge-utils package (/sbin/brctl)
10:20 < hikenboot>     * iproute package (/sbin/ip)
10:20 < hikenboot>     * hotplug or udev
10:21 -!- hollisb [~hollisb@user-0vvde2g.cable.mindspring.com] has joined #xen
10:24 -!- athomas [~athomas@host86-136-8-246.range86-136.btcentralplus.com] has joined #xen
10:45 -!- felix [~felix@AMontpellier-104-1-16-95.w193-252.abo.wanadoo.fr] has joined #xen
10:54 -!- Sir_Ahzz [~ahzz@c-24-0-241-237.hsd1.tx.comcast.net] has quit [Quit: Client exiting]
10:56 -!- rpg [~rpg@pixpat.austin.ibm.com] has joined #xen
11:07 -!- hikenboot [~hikenboot@c-24-218-84-234.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
11:10 -!- hollisb [~hollisb@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
11:10 -!- hollisb [~hollisb@pixpat.austin.ibm.com] has joined #xen
11:15 -!- hikenboot [~hikenboot@c-24-218-84-234.hsd1.ma.comcast.net] has joined #xen
11:23 -!- jerone [~jerone@pixpat.austin.ibm.com] has joined #xen
11:23 -!- anball [~anball@bi01p1.nc.us.ibm.com] has joined #xen
11:29 -!- monrad [~mikkel@213083190131.sonofon.dk] has joined #xen
11:36 -!- pvanhoof [~pvanhoof@mailhost.newtec.be] has quit [Quit: Leaving]
11:39 -!- Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has joined #xen
11:43 -!- athomas [~athomas@host86-136-8-246.range86-136.btcentralplus.com] has quit [Remote host closed the connection]
11:53 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
11:56 -!- xterminus [nobody@00104bc8bd59.click-network.com] has quit [Ping timeout: 480 seconds]
11:58 -!- athomas [~athomas@host86-136-8-246.range86-136.btcentralplus.com] has joined #xen
12:01 -!- sdog [~sdog@62.58.98.210] has left #xen []
12:03 -!- aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Quit: Leaving]
12:13 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has quit [Ping timeout: 480 seconds]
12:16 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
12:21 -!- pdx6_ is now known as pdx6
12:22 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
12:22 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
12:35 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has joined #xen
12:50 -!- pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has joined #xen
13:00 -!- pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has left #xen [Leaving]
13:00 -!- pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has joined #xen
13:03 -!- athomas [~athomas@host86-136-8-246.range86-136.btcentralplus.com] has quit [Quit: Leaving]
13:35 -!- Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has quit [Quit: foo]
13:42 -!- xterminus [nobody@00104bc8bd59.click-network.com] has joined #xen
13:55 -!- shaun [~Shaun@ip68-4-213-166.oc.oc.cox.net] has joined #xen
14:02 -!- kmacy [~kmacy@c-67-164-28-190.hsd1.ca.comcast.net] has joined #xen
14:04 -!- jerone [~jerone@pixpat.austin.ibm.com] has quit [Remote host closed the connection]
14:07 < kmacy> aliguori: ping
14:07 < aliguori> kmacy, pong
14:07 < kmacy> so, evidently he has gotten too many requests to make everyone
14:08 < kmacy> In other words
14:08 < aliguori> :-(
14:08 < kmacy> the schedule is being dictated by those for whom they didn't screw up the mailings
14:09 < kmacy> judging from the initial summit, event planning does not appear to be a forte' of anyone in Cambridge or Palo Alto
14:10 < aliguori> kmacy, do you have any interest in sound virtualization?
14:10 < kmacy> yes
14:10 < aliguori> kmacy, you want to cover it at the summit with me then?
14:10 < aliguori> :-)
14:11 < kmacy> well .... - I've never looked at a sound driver before - I could probably figure out what I need to know in a few hours, but you'd need to tell me where to look
14:12 < aliguori> kmacy, I'll do some research tonight and send you some stuff
14:12 < kmacy> cool
14:12 < muli> aliguori, I'm interested in sound virtualization as well
14:12 < aliguori> kmacy, I cc'd you on my response to Ian.. apparently, we were supposed to confirm that we could speak if we were on the agenda :-)
14:12 < aliguori> muli, coolness, I'll CC you too
14:13 < muli> btw, para or full? e.g. sndfront/sndback or emulation? what did you have in mind?
14:14 < kmacy> given the current overhead of emulation
14:14 -!- jerone [~jerone@pixpat.austin.ibm.com] has joined #xen
14:14 < kmacy> I'd be more interested in the former
14:15 < muli> ok, good
14:15 < muli> btw, aliguori, gregkh is now suggeting a syscall for privcmd
14:15 < muli> didn't we discuss this a while back? was there a compelling reason not to do a syscall?
14:15 < kmacy> hmm
14:15 < muli> except for it being per specific hypervisor, of course
14:15 < kmacy> I'm wondering if I should do the same
14:16 < kmacy> In FreeBSD, at least, one can dynamically add syscalls
14:16 < kmacy> so here it doesn't matter
14:16 < aliguori> muli, I don't know, what is the criteria for a syscall?
14:16 < aliguori> I'm very ignorant in this area
14:16 < muli> and even then is not quite right - the *implementation* is per hypervisor, the interface could accomodate multiple hypervisors 
14:16 < muli> aliguori, mostly "there's no better way to express what it means" :-)
14:17 < muli> i.e., none of dev file, /proc, /sys, foofs, netlink fit it
14:17 < muli> kmacy, what's the point in adding syscalls dynamically?
14:17 < kmacy> well
14:17 < kmacy> kernel modules can add them
14:18 < kmacy> one isn't restricted to drivers
14:18 < kmacy> I mean ioctl
14:18 < muli> kmacy, but then userspace needs to handle both cases, where it exists and it doesn't
14:18 < kmacy> same is true with ioctls..
14:18 < kmacy> or any other interface
14:19 < muli> also, it lowers the barrier to entry for new syscalls, which is not always a good thing (does FBSD have out-of-tree modules?)
14:19 < kmacy> except for drivers, not really
14:19 < kmacy> not in the way linux does
14:20 < muli> bbl, pizza's here
14:20 < kmacy> I haven't actually seen the dynamically registered syscalls used in a real application
14:20 < kmacy> much less abused
14:36 -!- edsuom [~edsuom@207-118-92-222.stat.centurytel.net] has joined #xen
14:36 -!- edsuom [~edsuom@207-118-92-222.stat.centurytel.net] has quit [Quit: ]
14:36 -!- edsuom [~edsuom@207-118-92-222.stat.centurytel.net] has joined #xen
14:38 < mdday> muli: I think problem with syscall is that it is supposed to be a canonical interface into the kernel from userspace, so it is not supposed to change. One new syscall is not a big deal but then every weird module will think it is entitled to a syscall of its own. Technically a syscall for userspace hypercalls is a great solution. 
14:39 -!- XenAddict [~XenAddict@217.132.17.97] has joined #xen
14:39 < mdday> whoops, I guess I'm wrong again, gkh says it's ok iv every hypervisor adds a syscall. 
14:40  * aliguori is curious to see what other kernel folks think
14:40 < mdday> yes, me too
14:41 < mdday> syscall would be easier to hack than a r/w into mapped memory, given the similarity between ioctl and syscall
14:43 -!- tessier [~treed@rrcs-67-53-110-66.west.biz.rr.com] has quit [Quit: Leaving]
14:45 < XenAddict> Hello,
14:45 < XenAddict>   I have a question which bothers me regarding running domain 0 in ring 3 
14:45 < XenAddict> 	in x86_64; is there somebody who might solve this question which puzzles me 
14:45 < XenAddict> 	for some time ? (and I must confess I am not an expert on this matters)
14:45 < XenAddict> 	
14:45 < kmacy> ioctl is a just a kitchen-sink syscall
14:46 < XenAddict> anybody here ?
14:47 < aliguori> XenAddict, why don't you just ask your question
14:47 < XenAddict> ok here it is:
14:47 < aliguori> XenAddict, you don't have to ask if you can ask your question :-)
14:48 < XenAddict> n x86, we have domain 0 running in ring 1 , and in x86_64 domain 0 
14:48 < XenAddict> 	runs in ring 3 (with the applications).
14:48 < XenAddict> 	
14:48 < XenAddict> 	Why is it so ? 
14:48 < XenAddict> As I understand, the x86 behaves according to the Intel IA32 manauals 
14:48 < XenAddict> 	while x86_64 behaves according to AMD 64 bit manuals (and correct me please 
14:48 < XenAddict> 	if I am wrong).
14:48 < XenAddict> 	
14:48 < XenAddict> 	But if I am not wrong in both cases, if you run a priveilegerd instruction it
14:48 < XenAddict> 	does not matter if it was issued from ring 1 or ring 3 ; Am I correct in this? 
14:48 < XenAddict> 	
14:48 < XenAddict> 	Why , when running x86_64, we run domain 0 in ring 3 and not in ring 1 (as 
14:48 < XenAddict> 	in x86 case)?
14:48 < shaun> am i using this correctly, vif = [ 'vifname=ttylinux' ]. i'm trying to set the interface on the host side to be named ttylinux and not vifXXXX
14:50 < hollisb> XenAddict: ring 1 has kernel memory privileges
14:50 < hollisb> XenAddict: ring 3 has user memory privileges
14:51 < aliguori> XenAddict, you're whitespace is killin my eyes btw :-) just leave one line of text per message please
14:51 < XenAddict> hollisb: ok, sorry.
14:51 < aliguori> XenAddict, ring 1/2 do not exist in 64 bit mode
14:51 < aliguori> so we hvae to run in ring 3
14:52 < XenAddict> aliguori: what is the difference between x86 and x86_64 in this aspect ? 
14:52 < XenAddict> aliguori: do they behave diffenetly ?
14:53 < aliguori> XenAddict, okay, first, a 64 bit processor (intel or amd) can run in 32 bit mode just fine
14:53 < aliguori> and the 64 bit manuals cover the 32 bit stuff
14:53 < aliguori> XenAddict, in 64 bit mode, a number of legacy features that exist in 32 bit mode that aren't commonly used were removed
14:53 < aliguori> namely, segmentation and ring 1/2
14:54 < aliguori> XenAddict, Xen does make use of both of these features though so we had to do things a bit differently for the 64 bit version of Xen
14:54 < XenAddict> aliguori: now I remeber that I saw somewhere that ring 1/2 does not exist in 64 bit mode 
14:55 < aliguori> XenAddict, plus, without segmentation, even if ring 1 did exist, we couldn't use it
14:55 < aliguori> XenAddict, b/c ring 1 has all the same access to memory as ring 0
14:55 < aliguori> XenAddict, in 32 bit mode, we use segmentation to protect a portion of memory so that ring 1 cannot access it
14:56 -!- bschulz [~bschulz@rchp4.rochester.ibm.com] has joined #xen
14:57 < XenAddict> aliguori: sorry for my ignorance reagrding 64 bit , but am I to understand that there is no segmentation in 64 bit ? I thing I saw that there are segmentation registers in AMD 64 bit manuals
14:57 < aliguori> XenAddict, for 32 bit mode
14:58 < aliguori> XenAddict, it's further complicated by the fact that some newer AMD 64 chips added back partial support for segmentation (at the request of vmware as they do the same tricks as we do)
14:58 < kmacy> aliguori: did we go to all the trouble of moving the guest into ring 3 for naught?
14:59 < kmacy> or rather they
14:59 < XenAddict> Aliguori : thnks ; this clears things; is there a chance that you remember the mode in which 64 bit operate ? is it something like "long "something
15:00 < aliguori> kmacy, there's still emt64
15:00 < aliguori> XenAddict, yup, it's called long mode
15:00 < kmacy> I imagine Intel will follow suit
15:00 < XenAddict> aliguori: thnks a lot !
15:01 < aliguori> kmacy, well, even if they do, the absense of ring 1 doesn't help us :-)
15:01 < aliguori> XenAddict, np
15:01 < kmacy> true
15:01 < aliguori> kmacy, that would let us avoid switching cr3 on every hypercall though.. which would help performance
15:01 < kmacy> so it works to your benefit that they've explored
15:01 < kmacy> exactly
15:05 < aliguori> it's particularly rough for vmware, b/c they need to run their dynamic translation code in the same address space as the application so without segmentation they have no hope
15:06 < hollisb> so VMware doesn't run on some AMD64 processors?
15:06 < aliguori> hollisb, nope
15:07 < aliguori> hollisb, on on emt64 bit processors... it's quite possible they will with VT though
15:08 < kmacy> aliguori: not the current batch
15:08 < kmacy> VT has too much overhead
15:10 < XenAddict> kmacy: may I ask , by saying "too much everhead" is it because of frequent VMX entries and exits?
15:10 < XenAddict> Or something else?
15:15 < kmacy> they're dynamic translation gives much lower overhead than VMEnter/VMExit
15:15 < aliguori> for now
15:16 < kmacy> that is why I say "not the current batch"
15:16 < aliguori> yeah :-)
15:17 < XenAddict> kmacy:thnks
15:23 < jerone> hollisb: yeap VMware 64bit doesn't run on a lot of the AMD64 cpus out there
15:24 -!- Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
15:39  * kmacy migrates to desktop
15:47 -!- tioui [~ptitlouis@AReims-151-1-104-167.w86-198.abo.wanadoo.fr] has joined #xen
15:48 -!- edsuom [~edsuom@207-118-92-222.stat.centurytel.net] has quit [Quit: KVIrc 3.2.0 'Realia']
15:51 < aliguori> XBT_NULL?
15:51 < aliguori> ugh
15:51  * aliguori 's eyes bleed
15:57 -!- alexandre [~Alexandre@200.103.151.93] has joined #xen
15:59 < kmacy> XBT_NULL?
16:00 < aliguori> yeah, for some reason, xenbus.h has #define XBT_NULL 0
16:00 < aliguori> and it's used through the xenbus code
16:00 < kmacy> wow
16:00 < hollisb> that was a very recent changeset I think
16:00  * aliguori shakes his head
16:00 -!- AlexMBas [~Alexandre@200.103.243.152] has quit [Ping timeout: 480 seconds]
16:00 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
16:02  * kmacy loves it the way GNU packages install themselves under /usr/local/include
16:02 < kmacy> but they look for each other in /usr/include
16:04 < tab> aliguori: what's wrong with XBT_NULL ?
16:05 < kmacy> tab: what's wrong with NULL?
16:05 < tab> kmacy: NULL is a pointer ...
16:05 < kmacy> where is XBT_NULL used?
16:06 < tab> where you want a NULL transaction as in no transaction ..
16:06 < kmacy> ahh
16:07 < kmacy> I guess what might bother people is the mapping in their minds of NULL to NULL pointer
16:07 < tab> and the transaction has noting to do with a pointer anymore, it's a plain integer
16:07 < tab> true, I could have put maybe XBT_NONE
16:08 < kmacy> That might be more generally palatable
16:08 -!- Sir_Ahzz [~ahzz@c-24-0-241-237.hsd1.tx.comcast.net] has joined #xen
16:08 -!- mode/#xen [+o Sir_Ahzz] by ChanServ
16:08 < tab> that was too much letters to change I guess ;)
16:09 < aliguori> tab: because NULL means NULL.
16:10 < tab> aliguori: that's the point
16:10 < aliguori> overloading the meaning over NULL with a prefix is just a bad idea
16:10 < tab> i'm not overloading anything 
16:11 < aliguori> NULL is for pointers
16:11 < kmacy> gotta love GRUB
16:11 < kmacy> talk about linux-centric
16:11 < aliguori> transaction types are not poitners :-) they're integers
16:11 < hollisb> kmacy: how so?
16:11 < tab> aliguori: they use to be ..
16:11 < tab> and the point is, you don't care about the type of the transaction
16:11 < kmacy> hollisb: is memalign implemented anywhere outside of glibc?
16:12 < hollisb> kmacy: I've seen people talk about that
16:12 < hollisb> kmacy: are you looking at GRUB2?
16:12 < aliguori> tab: why was it changed to an integer btw?
16:13  * aliguori would think a strongly typed opaque struct would be the best thing
16:13 < kmacy> or at least an enum
16:13 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
16:13 < tab> aliguori: because they were use as such
16:14  * aliguori shrugs
16:15 < tab> aliguori: well a struct would have been nice, but a bit overkill to add macro here and there to wrap it
16:17 < aliguori> tab: where would you need a macro?
16:17 < tab> allocate a xbt from string
16:18 < aliguori> what function does that now?
16:18 < tab> a plain strtol
16:18  * katzj gets signed up for doing a presentation next week... now to write something ;-)
16:18 < aliguori> tab: oh, when you're decoding the protocol?
16:18 < tab> decoding the protocol ??
16:19 < aliguori> I'm confused at where you need to strtol() to get a transaction id
16:19 < tab> because xenbus return everything as strings
16:19 < aliguori> yes
16:19 < aliguori> so when you're decoding the xenbus protocol :-)
16:19 < tab> so is the transaction id
16:19 < tab> it's not like it's really encoded..
16:20 < aliguori> yes, ok, it would require malloc()'ing the struct xenbus_transaction, setting a member in it to the integer, and returning the pointer
16:20 < aliguori> tab: i know i'm busting your balls here a bit :-)
16:20 < tab> and it's totally overkill to malloc a single integer ..
16:21 < aliguori> the integer type doesn't bother me nearly as much as the XBT_NULL.. but even that is not enough to make me want to code up a patch
16:21 < aliguori> tab: it's strong typing vs. weak typing...
16:21 < tab> well, maybe you could have done the cleanup then ..
16:21 < tab> it use to be an integer store in a pointer ..
16:21 < tab> you should be glad I clean this mess
16:21 < aliguori> :-)
16:22 < tab> aliguori: it's overdesigning vs KISS i'ld say ;)
16:22 < kmacy> tab: well talk to rusty
16:22 < kmacy> that is what happened in the first place
16:23 < kmacy> You're stuck picking up the pieces
16:23  * aliguori doesn't think anyone is happy with the store at this point
16:23 < aliguori> i think we all can agree on that at least :-)
16:23 < kmacy> so aliguori should shutup ;-)
16:23 < tab> indeed :)
16:23 < aliguori> kmacy, why thank you :-)
16:23  * aliguori goes and hides in a corner
16:24 < tab> (indeed was about the store btw)
16:24 < aliguori> tab: hehe
16:25 < aliguori> tab: i'm interested to see what the discussion is at the summit about it
16:25 < tab> I've no idea
16:25 < kmacy> aliguori: regardless of what Cambridge does
16:25 < tab> not even sure what it's going to be discuss at all actually ..
16:25 < kmacy> FreeBSD will probably switch xenbus to rusty's model
16:26 < kmacy> it would eliminate half the code
16:26 < kmacy> and allow much cleaner integration with their bus model
16:26 < aliguori> kmacy, which would that be?
16:26 < aliguori> kmacy, the no threading?
16:26 < kmacy> right
16:26 < kmacy> being able to query the store synchronously
16:27 < aliguori> the big xenbus lock :-)
16:27 < kmacy> well I don't know if you'd even need that
16:27 < kmacy> but that would be ok
16:27 < kmacy> xenbus isn't exactly a performance bottleneck
16:27 < kmacy> you have a version counter at the top
16:27 < kmacy> and one at the bottom
16:27 < kmacy> so you get a CAS effect
16:28 < kmacy> just like with the clock
16:28 -!- XenAddict [~XenAddict@217.132.17.97] has quit [Quit: Leaving]
16:28 < aliguori> CAS effect?
16:28 < tab> where's the drug dealer ? :)
16:28 < kmacy> heh
16:28 < kmacy> I haven't given it a lot of thought
16:29 < aliguori> heh
16:29 < kmacy> but why couldn't one have a version at the top and the bottom
16:29 < kmacy> if they didn't match, try again
16:29 < kmacy> ?
16:30 -!- Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
16:31 < aliguori> kmacy, so you're saying, increment something at the top, decrement it at the bottom, and don't enter until it's 0?  via an atomic getset?
16:31 < aliguori> aren't you just describing a mutex
16:32 < kmacy> no
16:32 < aliguori> you could also do it incrementing only and check if the top and bottom match, but again, it's just a mutex
16:32 < kmacy> no, actually that is optimistic concurrency
16:33 < kmacy> you have to try again if they don't match
16:33 < kmacy> if you grab a mutex, you have it
16:33 < aliguori> oh, you're saying, just return EAGAIN
16:33 < aliguori> i gotcha
16:33 < aliguori> you essentially want a trylock
16:33 < kmacy> well that would work too
16:34 < kmacy> but I'm saying:
16:34 < kmacy> incr counter
16:34 < kmacy> read values
16:34 < kmacy> incr bottom_counter
16:34 < kmacy> if counter 
16:34 < kmacy> != bottom_counter  try again
16:35 < kmacy> so you would actually re-do the work if you we're interrupted
16:35 < aliguori> ok
16:35 < kmacy> a mutex would be
16:35 < kmacy> lock
16:35 < kmacy> read values
16:35 < kmacy> unlock
16:36 < kmacy> you'd have a strong guarantee, but more overhead
16:36 < aliguori> why not a spin lock then?
16:36 < kmacy> That seems gross to me
16:36 < aliguori> hehe
16:36 < kmacy> having two domains potentially spinning on the same lock
16:37 < kmacy> e.g. I want the lock, but xenstore is updating
16:37 < kmacy> I guess trylock would give the same effect
16:37 < kmacy> but I don't ever want to block
16:38 < kmacy> I really don't like the idea of a domain actually blocking on xenstore
16:38 < aliguori> i guess it's the difference of spinning verses retrying an operation that's going to fail
16:39 < kmacy> well
16:39 < kmacy> how long lived are the updates?
16:39 < aliguori> depends i guess
16:39 < aliguori> if you had a very large store
16:39 < aliguori> and were starting a transaction
16:40 < aliguori> xenstore could delay for a fair amount of time copying the tdb
16:40 < kmacy> ptttht
16:40 < aliguori> especially if there was a healthy amount of IO already
16:40 < kmacy> device info should be in memory
16:40 < kmacy> it isn't persistent anyway
16:40 < kmacy> I would have it in a shared page
16:41 < kmacy> that doesn't need to go to disk
16:41 -!- nextime [~nextime@213-140-6-103.ip.fastwebnet.it] has quit [Quit: No windows for this server]
16:41 < kmacy> persisten store is for persistent values
16:41  * aliguori shrugs
16:42 < kmacy> well
16:42 < kmacy> why not?
16:42 < aliguori> kmacy, I agree with you
16:42 < tab> actually me too
16:43 < kmacy> cool :-)
16:44 < aliguori> kmacy, that's why rusty wants to move all device info into shared memory
16:45 < kmacy> aliguori: if Cambridge doesn't like the idea, he is welcome to develop it in FreeBSD :-)
16:47 < hollisb> aliguori: would both dom0 and domU need to grok the same data format in that case?
16:47 < hollisb> making backwards compatibility difficult?
16:48 < kmacy> hollisb: yes
16:48 < kmacy> unless you had some way of switching between the two
16:48 < kmacy> which wouldn't be that hard
16:48 < kmacy> you could pass it in on the command line
16:48 < hollisb> switching betweent the two what?
16:48 < kmacy> or set it in start_info
16:48 < kmacy> using the current asynchronous interface and a shared page interface
16:49 < aliguori> hollisb, i don't understand, why is it harder than in the store?
16:49 < hollisb> aliguori: the store keeps the same interface regardless of the format used in dom0, no?
16:50 < kmacy> hollisb: actually dom0 is independent
16:50 < kmacy> or is it?
16:50 < aliguori> whatcoo talkin' bout hollisb
16:50 < aliguori> hollisb: what do you mean by "interface" and "format"?
16:51 < hollisb> interface: "get me this key"
16:51 < hollisb> format: "oh, I happen to know I've stored that key in a tdb file"
16:52 < aliguori> ohhh
16:52 < hollisb> so in shared memory, both domains would need to agree on the format being used
16:52 < aliguori> hollisb, okay, well instead, it would be the devices are stored in the following structure in shared memory
16:52 < aliguori> yeah
16:53 < aliguori> hollisb, i think i kind of understand your argument but I'm not sure I buy it.  if the format in shared memory is going to change, it's probably going to be because fields are added/removed which would happen in the store anyway
16:53 < aliguori> i don't think people will be randomly shuffling around fields or deciding to represent in big endian now
16:54 < hollisb> that always happens :)
16:54 < hollisb> it will start simple and evolve
16:55 < aliguori> hollisb, one could follow good practices though, always add to the end of a structure, etc.
16:55 < aliguori> make extra room
16:56 < hollisb> mistakes will be made :)
16:59 < kmacy> hollisb: requiring threads to find your devices?
16:59 < kmacy> they already have been
16:59 < hollisb> kmacy: obviously I'm talking about a future-proof shared data structure... :)
17:00 < aliguori> hollisb, do you think xenbus is future proof though?  it's certainly changed quite a number of times already
17:00 < kmacy> There isn't anything stopping one from having key/value pairs in a shared page
17:01 < kmacy> using a packed struct is merely to save space
17:01 < hollisb> I really don't know, but having an interface is a lot easier to maintain
17:01 < hollisb> it's the classic design thing
17:01 < hollisb> do you expose all your private data? or do you provide a read/write interface?
17:02 < hollisb> keeping private data private means you're free to change it whenever you like
17:02 < kmacy> where does private data come in?
17:02 < kmacy> it has to be in some format
17:03 < kmacy> if that format changes
17:03 < kmacy> the it has to be changed for the consumer somewher
17:03 < kmacy> e
17:03 < hollisb> kmacy: I'm talking about the format the data is stored in
17:03 < hollisb> is it key/value? is it a tree? linked list?
17:03 < hollisb> it's the same data in all cases
17:04 < hollisb> organized differently
17:04 < kmacy> for devices 
17:04 < kmacy> who cares
17:04 < kmacy> if you're doing something fancy
17:05 < kmacy> you've gone overboard
17:05 < hollisb> we must not be talking about the same thing
17:05 < kmacy> plus the store can represent internally however it chooses
17:05 < kmacy> it just has to be consistent in how it presents it to guests
17:06 < thelsdj> well finally tracked down my reboot on guest domain start to revision 8525, 8524 i can start vmx and non vmx guests, but after that the system just reboots
17:06 < hollisb> kmacy: I'm talking about domU drivers having to agree on the format with dom0, the owner of xenstore
17:06 < hollisb> kmacy: that would be bad
17:06 < kmacy> agreed
17:06 < hollisb> ok :)
17:06 < kmacy> I don't think that what I'm talking about would require that 
17:07 < kmacy> early in boot-time the guest could tell the store how it wanted the data presented
17:07 < hollisb> hmm
17:08 < thelsdj> anyone know how to make mercurial undo just one revision (not the most recent?) may not work but would be interesting to try latest unstable tree with just the 8525 patches removed
17:08 < hollisb> thelsdj: hg export <rev> | patch -R
17:11 -!- womble [~mpalmer@220-245-224-46.static.tpgi.com.au] has joined #xen
17:15 < kmacy> hollisb: dom0 doesn't need to know anything
17:15 < kmacy> and xenstore just needs to know how a domU wants to consume its data
17:16 < aliguori> if devices are brought up via shared memory descriptions, there's no need for xenstore anymore.
17:17 < kmacy> aliguori: ???
17:17 < aliguori> kmacy, ???
17:17 < aliguori> :-)
17:17 < kmacy> someone has to mmap the shared pages
17:17 < aliguori> yeah, whoever creates the domain
17:17 < kmacy> and write the data to them
17:17 < aliguori> see above
17:17 < aliguori> :-)
17:18 < kmacy> right
17:18 < kmacy> well in the interim 
17:18 < kmacy> since all the scripts talk to xenstore
17:18 < tab> glad i'm not the only one with a problem with chgset 8525
17:18 < kmacy> I would simply add a shared page interface
17:18 < kmacy> I'd really like to see xend cut down
17:19 < kmacy> when you boot diskless
17:19 < kmacy> you can't restart xend
17:19 < thelsdj> tab: what is your problem?
17:20 < tab> it crash Xen when I'm starting a domain
17:20 < thelsdj> what processor?
17:20 < thelsdj> any changesets after that work?
17:20 < tab> the processor probably doesn't matter
17:21 < tab> as of yesterday I didn't find any, that did
17:21 < tab> I had to update to 8524 and do my testing with that
17:21 < thelsdj> ya, i'll give latest a go tomorrow probably
17:22 < tab> I don't think that's going to fix anything ..
17:22 < thelsdj> you have a guess as to what in that change broke it?
17:22 < tab> unfortunately not :(
17:22 < tab> keir neither
17:23 < tab> it doesn't look it's broking anything, and yet ..
17:23 < thelsdj> weird
17:24 < tab> thelsdj: you should report it to the list
17:24 < tab> hopefully somebody will fix it this way
17:25 < kmacy> tab
17:26 < kmacy> look at the top of the changeset
17:26 < kmacy> is arch no longer a member of vcpu?
17:27 < kmacy> i.e. did it get changed to being a pointer
17:27 < kmacy> I don't have the latest
17:27 < kmacy> neverm 
17:28 < kmacy> never mind
17:28 < kmacy> I guess the idle vcpu must have been a special case
17:29 -!- felix_ [~felix@AMontpellier-104-1-16-75.w193-252.abo.wanadoo.fr] has joined #xen
17:29 < Basic_py> Can you compile a dom0 kernel i386? make menuconfig select i386 and deselecting smp, I get 'include/asm/atomic.h:200: warning: implicit declaration of function `smp_processor_id''
17:30 < tab> kmacy: it was as far as I understand (cf Keir's changeset comment)
17:31 < aliguori> Basic_py, did you specify ARCH=xen?
17:31 < Basic_py> yep
17:31 < tab> Basic_py: you can't :)
17:31 < Basic_py> tab: dom0 kernel cannot be i386?
17:32 < tab> you can just add "#include <linux/smp.h>" in arch/i386/kernel/i8237.c
17:32 < aliguori> oh, good catch tab, it's cause it's gotta be arch xen
17:32 < tab> I suppose you are trying to build linux-2.6-merge.hg
17:32  * aliguori is confused
17:32 < aliguori> ohhhhh
17:32 < aliguori> :-)
17:32 < tab> there's a big include mess there
17:33 < tab> and I cannot find the good solution
17:33 < tab> Basic_py: or select SMP, it will solve the problems too
17:33 < Basic_py> i386 and smp selected via menuconfig gives me the same smp warnings
17:34 < Basic_py> I have a via chip that doesn't support the extended move op code and gcc generates improper code for pentium or higher chipsets
17:34 < Basic_py> so, trying to get xen to compile a i386 kernel 
17:35 < Basic_py> it looks like 486 kernel is compiling clean
17:35 < tab> you can compile a pentium instruction set with that
17:35 < tab> But I don't think that xen works on the C3
17:36 -!- felix [~felix@AMontpellier-104-1-16-95.w193-252.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:36 < Basic_py>  cpuinfo here http://www.rafb.net/paste/results/w0rPEV79.html
17:41 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
17:42 < xterminus> for vnc support to be included correctly, what version of libvncserver-dev should i have installed?
17:43 < xterminus> the package that comes with sarge seems to be too old (i'm guessing)
17:44 -!- dme [~dme@host-84-9-60-139.bulldogdsl.com] has quit [Remote host closed the connection]
17:45 < aliguori> xterminus, just grab it from libvncserver.sf.net
17:45 < aliguori> xterminus, you have a VT machine right?
17:46 < xterminus> okay i'll just use the cvs sources then, and define vt
17:46 < xterminus> :)
17:47 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
17:48 < xterminus> want to get xen's vnc working like its supposed to ... doing a xen demo for my lug next week
17:48 < xterminus> right now vnc works, but without any help from xen :)
17:48 < aliguori> xterminus, if you don't know that you have a VT machine, you don't have one
17:49 < aliguori> VT is the processor extensions available only in the very latest new pentium chips which are not all that available just yet
17:49 < aliguori> Xen's VNC support is limited to full virtualization
17:50 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
17:53 < xterminus> no then, my machine is only a athonxp 2800
17:55 < xterminus> i'll probably buy the amd (pacifica) when it comes out though
17:57 < xterminus> and yay - my monster rsync snapshot script looks like it works - now i can start backing up domu's on a hourly/daily/weekly/monthly basis
18:00 -!- bschulz [~bschulz@rchp4.rochester.ibm.com] has quit [Quit: Leaving]
18:06 < xterminus> i read somewhere that you can give a domu control of a pci device, this possible still in xen3?
18:06 -!- thelsdj [~thelsdj@24-116-69-69.cpe.cableone.net] has quit [Read error: Connection reset by peer]
18:07 < kmacy> no
18:07 < kmacy> not yet at least
18:07 < kmacy> look for "driver domains"
18:11 < xterminus> hrm - it'd be nifty to give a domu access to the video/sound card or say the usb controller (i dont care about sharing those devices just so long as dom0 doesnt have to manage them like now)
18:25 -!- toks [~toks@bi01p1.nc.us.ibm.com] has quit [Quit: Leaving]
18:26 < xterminus> http://lists.xensource.com/archives/html/xen-devel/2006-01/msg00184.html - so definately not yet :)
18:36 -!- xterminus [nobody@00104bc8bd59.click-network.com] has left #xen [[IRSSI] Fighting for peace is like screwing for virginity.]
18:36 -!- hollisb [~hollisb@pixpat.austin.ibm.com] has quit [Quit: leaving]
18:47 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
18:49 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
18:50 -!- felix_ [~felix@AMontpellier-104-1-16-75.w193-252.abo.wanadoo.fr] has quit [Quit: Client exiting]
18:54 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
18:57 -!- Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
18:59 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:00 -!- kmacy [~kmacy@c-67-164-28-190.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds]
19:01 -!- anball [~anball@bi01p1.nc.us.ibm.com] has quit [Quit: Leaving]
19:02 -!- anball [~anball@bi01p1.nc.us.ibm.com] has joined #xen
19:02 -!- dhendrix [~dhendrix@pcp0011791675pcs.losala01.nm.comcast.net] has quit [Quit: Leaving]
19:02 -!- jerone [~jerone@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:07 -!- xterminus [nobody@00104bc8bd59.click-network.com] has joined #xen
19:08 < xterminus> hrm, this xen vnc thing is not working out
19:09  * xterminus tries again
19:09 -!- xterminus [nobody@00104bc8bd59.click-network.com] has left #xen []
19:09 -!- kmacy [~kmacy@c-67-164-28-190.hsd1.ca.comcast.net] has joined #xen
19:09 -!- rpg [~rpg@pixpat.austin.ibm.com] has quit [Remote host closed the connection]
19:16 -!- Basic_py [~Basic@gatekeeper.real-time.com] has quit [Quit: Leaving]
19:16 -!- xterminus [nobody@00104bc8bd59.click-network.com] has joined #xen
19:17 -!- dhendrix [~dhendrix@pcp0011791675pcs.losala01.nm.comcast.net] has joined #xen
19:17 < xterminus> is there any way to tell if vnc was sucessfully included with xen?
19:18 < xterminus> when i create a new domu with xm create vmid=2 vnc=1 - xend isn't passing off the listener parameter to the domu
19:22 < katzj> xterminus: are you using VT hardware?  the vnc stuff only has meaning for VMX guests
19:24 < xterminus> oh
19:26 < xterminus> i thouht the vnc stuff was simply for setting up vnc period
19:27 -!- thelsdj [~thelsdj@24-116-69-69.cpe.cableone.net] has joined #xen
19:37 -!- pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has quit [Ping timeout: 480 seconds]
19:43 < xterminus> thanks, i'll just go with setting up domu's as vnc terminal servers
20:06 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:13 -!- dansmith [~dan@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
20:14 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
20:39 -!- Basic_py [~Basic@warden.real-time.com] has joined #xen
20:44 -!- xterminus [nobody@00104bc8bd59.click-network.com] has quit [Ping timeout: 480 seconds]
21:04 -!- homebaum [~michael@pool-71-245-110-7.ptldor.fios.verizon.net] has joined #xen
21:10 -!- _David_ [~david@202.148.226.15] has joined #xen
21:14 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
21:16 -!- nags [~nags@202.144.95.244] has joined #xen
21:20 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
21:21 -!- JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has quit [Quit: What does it mean if the end of time is imaginary?]
21:21 -!- JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has joined #xen
21:24 -!- thelsdj [~thelsdj@24-116-69-69.cpe.cableone.net] has quit [Ping timeout: 480 seconds]
21:26 -!- dhendrix [~dhendrix@pcp0011791675pcs.losala01.nm.comcast.net] has quit [Quit: Leaving]
21:32 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
21:39 -!- aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
22:01 -!- mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
22:15 -!- minemaz [~mine@softbank220055148023.bbtec.net] has quit [Read error: Connection reset by peer]
22:15 -!- minemaz [~mine@softbank220055148023.bbtec.net] has joined #xen
22:25 -!- minemaz [~mine@softbank220055148023.bbtec.net] has quit [Read error: Connection reset by peer]
22:41 -!- minemaz [~mine@softbank220055148023.bbtec.net] has joined #xen
22:57 < kmacy> aliguori: ping
23:01 -!- Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
23:04 < aliguori> kmacy, pong
23:04 < aliguori> kmacy, i just rewrote the framebuffer so that x now works over vnc
23:04 < aliguori> but i can't tell if i have bugs or libvncserver just sucks
23:08 < kmacy> hmm
23:08 < kmacy> I'll take a look after the summit
23:08 < kmacy> have you ever looked at freenx?
23:08 < hikenboot> aliguori: I successfully got NXFree working with Xen
23:09 < kmacy> heh heh
23:09 < kmacy> hikenboot, you mean FreeNX
23:09 < hikenboot> sorry yes
23:09 < hikenboot> only thing i had problems with is getting sound to work in gnome..worked fine in kde but not gnome
23:10 < kmacy> aliguori, I'm also going to present a couple of slides and a demo of gdbserver
23:10 < kmacy> hmm
23:10 < aliguori> cool
23:10 < kmacy> hikenboot, I have to think that is a gnome issue and not a xen issue
23:11 < hikenboot> probably but I was over my head and couldnt figure it out and neither could anyone I found
23:11 < kmacy> aliguori: so I'm going to start jotting down slides tonight
23:11 < hikenboot> I forget the error I got and unfortuanlly lost a few links in a system crash
23:11 < kmacy> demoing it will be easy, if I can find a projector with adequate resolution
23:11 < aliguori> kmacy, you're making slides?
23:12 < aliguori> i was hoping to avoid slides
23:12 < kmacy> It depends on how much work it is
23:12 < aliguori> :-)
23:12 < kmacy> very very straightforward slides
23:12 -!- johnlev [~johnlev@nwkea-socks-1.sun.com] has quit [Remote host closed the connection]
23:12 < kmacy> no graphics
23:12 < hikenboot> anyone know what this error means on an initrd image warning: gids truncated to 8 bits (this may be a security concern)?
23:12 < aliguori> i have to install my an old laptop too... my current laptop won't do vga output
23:13 < kmacy> hikenboot: group id
23:13 < kmacy> hikenboot: basically losing differentiation
23:13 < kmacy> I wouldn't worry on a single user machine
23:13 < kmacy> I don't know what else gids could be referring to
23:13 < hikenboot> well right now thats me!
23:14 < aliguori> hikenboot, i've seen that output from mkcramfs
23:14 < hikenboot> eventually i want to setup systems for clients
23:14 < kmacy> hikenboot: unless you have > 255 groups don't worry too much
23:14 < hikenboot> i found several articles about it but no solutions
23:14 < hikenboot> oh thats huge ..I only work with small and medium sized business anyways
23:14 < kmacy> otherwise one would need to hack cramfs
23:15 < aliguori> i think it's a cramfs feature
23:15 < kmacy> probably easy, but not very interesting work
23:15 < hikenboot> ummm...feature...or umm..bug?
23:15 < aliguori> feature
23:15 < aliguori> less space required per inode
23:15 < kmacy> 8 bits
23:15 < kmacy> as opposed to 16 or 32
23:15 < hikenboot> ah ok i get it sure 255
23:16 < kmacy> if space is tight, why waste it
23:16 < kmacy> not that getting grub to compile is particularly fascinating
23:17 < aliguori> cramfs is pretty nuts with that sort of stuff.. it stores no {a,c,m}time either
23:17 < hikenboot> question for you guys! When do you think xen with vt enabled hardware and running windows guests will be stable in a production environment?
23:17 < aliguori> hikenboot, 10 years is a pretty safe guess :-)
23:17 < aliguori> I'll put money on that number :-)
23:17 < hikenboot> gee dont say that
23:17 < kmacy> atime and ctime are silly for that sort of thing anyway
23:17 < aliguori> hikenboot, seriously, it's hard to say
23:17 < kmacy> hikenboot: for whom?
23:18 < aliguori> hikenboot, unlikely that it would be within a year
23:18 < kmacy> aliguori :-)
23:18 < aliguori> hikenboot, besides, systems with VT won't generally be available for at least a year anyway
23:18 < hikenboot> thats not what i want to here unfortuantely
23:18 < aliguori> by the time every new system is VT or SVM enabled, Xen will probably work well
23:18 < kmacy> hikenboot: I just ordered one
23:18 < hikenboot> I see
23:19 < hikenboot> kmacy: did you just say you ordered one for me?
23:19 < kmacy> but until there are PV drivers for windows
23:19 < kmacy> heh heh
23:19 < hikenboot> ;-)
23:19 < kmacy> it will not perform well
23:19 < hikenboot> PV?
23:19 < aliguori> bah, who wants to run windows anyway
23:19 < kmacy> Odds are, those will not be free for some time
23:19 < kmacy> windows is closed source
23:19 < kmacy> writing the drivers is real work
23:19 < hikenboot> unfortuanately there is a lot of stupid companies out there that insist that there a microsoft shop
23:20 < kmacy> aliguori: I do ;-)
23:20 < aliguori> kmacy, shame on you :-)
23:20 < kmacy> aliguori: I can't help it
23:20 < aliguori> just imagine vista too...
23:20 < kmacy> I've even looked at porn sites once or twice
23:20 < aliguori> the cirrus chip we're emulating now is going to crawl with vista
23:20 < aliguori> kmacy, lol!
23:22 < hikenboot> fact is here in the usa windows will be the common OS for the next 20 years while everywhere else in the world it might only be 10
23:22 < aliguori> just depends on what market you're in
23:22 < hikenboot> <---hikenboot reboots new xen compiled kernel with high hopes
23:24 < hikenboot> well i dont know enough to work for huge companies..and I dont want to work 70 hours a week working for a major company like ibm to get the experience..although i have been asked on several occasions.
23:24 < aliguori> hehe
23:24 < hikenboot> I just like the idea of working 40 hours and going home and doing my own thing
23:25  * aliguori 's life would be a lot easier if ibmers worked 70 hours a week :-)
23:25 < hikenboot> hikenboot reboots brb
23:25 -!- hikenboot [~hikenboot@c-24-218-84-234.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
23:25 < kmacy> aliguori: its easiest when home == work
23:25 < aliguori> kmacy, indeed :-)
23:25 < kmacy> I've got my servers in a closet
23:26 < kmacy> a comcast connection
23:26 < kmacy> and an SBC connection as backup
23:26 < aliguori> nice
23:26 < aliguori> I live less than a mile from the ibm office
23:33 < kmacy> how did anyone ever get grub to compile an a FreeBSD system?
23:33 < kmacy> it includes argp.h 
23:33 < kmacy> for GNU getopt
23:34 < kmacy> GRUB1 compiles on FreeBSD, but it doesn't support UFS2 :-(
23:37 -!- hikenboot [~hikenboot@c-24-218-84-234.hsd1.ma.comcast.net] has joined #xen
23:37 < hikenboot> hello all back again
23:38 < hikenboot> kernel compile wasnt a complete success...didnt detect my via_velocity network card...thought i had enabled it but guess not
23:40 < hikenboot> if i do make linux-2.6-xen-config CONFIGMODE=menuconfig will this overwrite my current config?
23:40 < kmacy> never tried that
23:41 < hikenboot> I want to conserve my current config but make a few changes
23:43 -!- zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Remote host closed the connection]
23:46 -!- zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
23:46 < hikenboot> hmm ...i did check off via-velocity but it wouldnt load the module...said module not found on modprobe
23:48 < hikenboot> ok going to build it right into the kernel!
23:51 < hikenboot> night everyone...compile will take all night so off to bed I go...wish someone would make the compilers run over a cluster...speed things up a bit!
23:56 < kmacy> hikenboot: that already exists
23:56 < kmacy> in a number of incarnations
23:56 < kmacy> aliguori: I'm confused
--- Log closed Thu Jan 12 23:59:00 2006