--- Day changed

--- Log opened Tue Apr 19 23:59:02 2005
00:19 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: Everybody wants to go to heaven, but nobody wants to die.]
00:37 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
00:53 -!- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
01:36 -!- JViz [Anomaly@cpe-024-163-002-218.triad.res.rr.com] has joined #xen
01:57 -!- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Read error: Connection reset by peer]
02:26 -!- N [~ca4bc809@webuser.thegrebs.com] has quit [Quit: http://thegrebs.com/oftc/ (Session timeout)]
03:09 -!- muli_ [~muli@nesher3.haifa.il.ibm.com] has quit [Read error: Connection reset by peer]
03:12 -!- muli_ [~muli@nesher3.haifa.il.ibm.com] has joined #xen
03:23 -!- N [~ca4bc809@webuser.thegrebs.com] has joined #xen
03:28 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [Ping timeout: 480 seconds]
03:31 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
03:49 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [Ping timeout: 480 seconds]
04:00 < mael> hi
04:01 < cw> howdy
04:11 < hebutterworth> hi
04:17 -!- cw [cw@adsl-67-124-119-21.dsl.snfc21.pacbell.net] has quit [Quit: better not oops :)]
04:33 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
04:43 < caker> !skas-2.6?
04:43 < caker> whoops, mcm
04:45 -!- anticw [cw@adsl-67-124-119-21.dsl.snfc21.pacbell.net] has joined #xen
04:45 -!- mode/#xen [+o anticw] by ChanServ
04:45 -!- anticw is now known as cw
04:59 -!- athomas [~athomas@hardpress.demon.co.uk] has joined #xen
05:03 -!- cw is now known as anticw
05:47 -!- deac [~deac@xdsl-84-44-215-62.netcologne.de] has quit [Read error: Operation timed out]
06:00 -!- deac [~deac@xdsl-81-173-137-130.netcologne.de] has joined #xen
06:05 -!- athomas [~athomas@hardpress.demon.co.uk] has quit [Quit: Leaving]
06:52 -!- soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
06:53 -!- uriel [~binarydre@green.eye.binarydream.org] has joined #xen
08:05 -!- yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has joined #xen
09:38 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
09:52 -!- athomas [~athomas@hardpress.demon.co.uk] has joined #xen
09:52 -!- athomas [~athomas@hardpress.demon.co.uk] has quit [Quit: ]
09:59 -!- unriel is now known as riel
10:13 < knewt> anyone know if the move of ACPI into dom0 has happened in -unstable yet?
10:37 -!- uriel [~binarydre@green.eye.binarydream.org] has left #xen []
10:37 -!- Bluefox [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit [Quit: http://ubuntulinux.org/ | http://gentoo.org]
10:39 -!- Bluefox [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
10:47 -!- N [~ca4bc809@webuser.thegrebs.com] has quit [Quit: http://thegrebs.com/oftc/ (Session timeout)]
10:48 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
10:58 -!- N [~ca4bc809@webuser.thegrebs.com] has joined #xen
11:15 -!- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
11:15 < aliguori-> mornin'
11:18 < rharper> aliguori: morning
11:19 < aliguori-> rharper: you wouldn't happen to know ash scripting would you?
11:20 < rharper> aliguori: I indeed am quite familiar with ash
11:20 < aliguori-> you use some different shell contructs than I'm used to.. i wondering if you know if they're available on ash (like {})
11:20 < aliguori-> awesome :-)
11:20 < rharper> heh, no, arrays arent available in ash
11:20 < rharper> =(
11:20 < rharper> do we need to be ash compat ?
11:20 < aliguori-> hmm, well, that's ok
11:21 < aliguori-> well
11:21 < rharper> I can respin
11:21 < rharper> will be uglier 
11:21 < aliguori-> i want to be, but don't worry about it for now
11:21 < aliguori-> i'm going to do an ash-compat pass at some point in the future
11:21 < aliguori-> b/c i want to make sure vm runs under busybox :-)
11:22 < rharper> so, ash supports things like ${foo}, thats just extra scoping, ash doesnt support foo=( `ls` ) , or ${foo[i]}
11:22 < rharper> yeah, arrays have to come out for busybox 
11:22 < aliguori-> there's other stuff in vm right now that prevent that.. thought i had removed them but apparently i didn't check it in
11:22 < rharper> I can rewrite for busybox sh 
11:22 < riel> ash is like bash, but with less richer syntax
11:22 < rharper> and no arrays =(
11:22 < aliguori-> yeah, and functions can't use the function keyword.
11:22 < rharper> ugh, yes
11:22 < riel> lack of arrays is annoying
11:23 < aliguori-> i've never actually used shell arrays..  and here i thought i used obscure shell stuff :-)
11:23 < rharper> aliguori: in my former job we abused arrays to no end, it was quite fun, almost perl-like in its obscurity 
11:24 < rharper> oh, IIRC, ash doesn do ${!p} either 
11:24 < rharper> so no function pointers 
11:24  * knewt played with them recently as a bit of fun in implementing perl "split" in pure bash shell script
11:24 < knewt> :)
11:24 < rharper> aliguori: no math in ash/bb, $((count+2)) 
11:25 < aliguori-> rharper: i didn't even know you could do function pointers.. i probably would have just eval'd to simulate it
11:25 < rharper> aliguori: yeah, thats what you have to do in ash 
11:25 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
11:25 < aliguori-> rharper: i have to check my root image and see if i've got bc in there
11:26 < rharper> you can use let 
11:26 < aliguori-> nope.
11:26 < rharper> let i=i+1 
11:26 < aliguori-> indeed.  neat
11:52 < mael> hi aliguori 
11:53 < mael> interesting conversation about DoS on xen lately
11:54 < mael> it seems that ressources sharing is still not implemented on every aspect of xen architecture
11:55 < mael> (I mean with quota/threshold/sharing algorithms and so on)
11:55 -!- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Read error: Connection reset by peer]
11:57 < mael> mmh either I'm a truly unlucky man or either I'm so boring they manage to get a tricky system to avoid my questions :)
11:57  * mael had the same "reset by peer" error a few days ago with rusty
12:00 < mael> well, time to go anyway
12:00 -!- mael [~mael@nat.inha.fr] has quit [Quit: see ya]
12:00 -!- anthony [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
12:02 < rharper> haha
12:03 -!- anthony is now known as aliguori-
12:06 < plars> what's the config parameter for multiple cpus in xenU?
12:06 < plars> config file that is, not kernel config
12:31 < plars> ahh, vcpus
12:31 < plars> rharper: did your cpumap stuff get in?
12:46 < rharper> plars: not yet 
12:46 < rharper> grinding on some dom0 op interface details
13:16 -!- cfreak [cfreak@dsl-084-056-099-111.arcor-ip.net] has joined #xen
13:26 < plars> oh cool, vcpus > cpus works already, didn't know that was the case
13:27 < riel> I've been using it for months ;)
13:30 -!- cfreak [cfreak@dsl-084-056-099-111.arcor-ip.net] has quit [Quit: .]
13:34 -!- hebutterworth_ [~harry@195.212.29.91] has joined #xen
13:37 -!- hebutterworth [~harry@blueice1n1.uk.ibm.com] has quit [Ping timeout: 480 seconds]
13:39 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
13:43 < cdub> riel: what was the vdso issue?
13:45 < riel> cdub: xen0 domain hangs with roland's latest vdso changes
13:45 < riel> (which are upstream)
13:45 < cdub> riel: did offset change? (i didn't look upstream yet, /me looks)
13:46 < riel> good question
13:48 < cdub> hmm, doesn't look like it (but i don't have most current tree ATM)
13:49 -!- mael [~mael@kali.tirnamban.org] has joined #xen
13:49 < riel> the vdso is mapped at a random offset
13:49 < riel> in a real vma
13:49 < riel> so it can work with execshield
13:50 < cdub> hrm, sounds potentially problematic, how did you work around that?
13:51 < riel> I don't have it working yet ;)
13:51 < cdub> ahhh, I see ;-)
13:51 < cdub> riel: I'm mucking in that area right now, hence the questions ;-)
13:52 < riel> arghhhhhh
13:52  * cdub ducks
13:52 < riel> I need to use the i386 vsyscall.lds.S not the xen vsyscall.lds
13:52 < riel> I think
13:52 < cdub> riel: that's what I'm trying to fix right now
13:53 < cdub> riel: xen needs proper offsets, rather than hardcoded vsyscall.lds (so the normal vsyscall.lds.S can work properly)
13:56 < eigood> xen still suffers a bit from NIH
13:56 < riel> *nod* (at cdub)
13:56 < eigood> instead of writing their own scheduler, io, etc, they should just be pure linux in ring 0, and modify the linux scheduler to schedule ring1 apps, instead of userspace/ring3
13:57 < eigood> including pipe support, for inter-domain communication
13:57 < riel> eigood: sounds like a bad idea to me
13:57 < eigood> why?
13:58 < riel> there are advantages to having a small and simple hypervisor
13:58 < mael> ring 1 and 2 disapeared on x86_64 arch, no?
13:58 < riel> also, think about driver domains
13:58 < riel> mael: but VT/Pacifica give back new rings ;)
13:58 < cdub> heh, true
13:58 < mael> well a 1/2 -1 ring at least
13:59  * mael is still perplex on the vmx stuff
13:59 < mael> fair scheduling seem very hard to manage with vmx
13:59 < eigood> riel: driver domains is like root in normal linux accessing hardware directly
14:00 < mael> eigood: in dom0 yes but not in unprivileged domains, if I understand correctly
14:00 < riel> eigood: not with Pacifica
14:01 < riel> eigood: domains can get access to only their own PCI devices and their own memory
14:01 < riel> eigood: no DMAing over other people's memory, either
14:01 < mael> riel: this is through the pci grant table of pacifica?
14:02 < riel> I think so
14:02 < riel> but I only saw the presentation at the xen summit ;)
14:02 < riel> no other info
14:02 < eigood> that sounds like IPC to me
14:02 < eigood> or netlink
14:02 < mael> ok I couldn't really understand the difference on the pacifica powerpoint presentation
14:02 < mael> this is the only document I was able to find
14:02 < eigood> driver domain uses netlink to the base xen/linux in ring0, to request access to resources
14:03 < mael> but it is mainly a commercial/marketing stuff
14:03 < eigood> driver domains and normal domains use IPC to send data
14:03 < cdub> eigood: at the cost of extra context switching
14:03 < riel> eigood: the point is that the device drivers run directly in the driver domain, not in dom0
14:03 < cdub> eigood: e.g. with pacifica you let hardware protect you  (iommu and dev exclusion vector or whatever it was called) once it's set up
14:04 < eigood> riel: where I have said that wouldn't still be the same?
14:04 < eigood> oh, wait, I did.
14:04 < mael> cdub: so they implemented the kind of hardware Mark's paper told about?
14:04 < eigood> well, if programming a pci device allows it to read/write to other memory, something has to filter said programming to validate it.
14:05 < cdub> mael: sorry, which paper?
14:05 < riel> eigood: the hardware filters that
14:05 < mael> cdub: the one on safe hardware sharing
14:05 < eigood> well, then pacifica allows things to be faster, and could be stubbed out on such systems
14:05 < eigood> but there are going to be lots of machine for quite a while yet that don't have the tech
14:05 < mael> I think the conclusion was that they missed a iommu stuff
14:06 < mael> (but I'm far from a good comprehension :))
14:06 < cdub> amd got that, it's intel that missed iommu
14:06 < riel> eigood: but do you want to optimise not-yet-ready software for hardware that might be obsolete by the time all the software features are implemented ?
14:06 < mael> uh ok
14:07 < mael> riel: well what about arch different than x86? what about ppc ia64 and so on?
14:08 < mael> do they have the same needed hardware? (the iommu stuff)
14:08 < riel> mael: ppc has an existing hypervisor interface already, which xen is being ported to
14:08 < cdub> ppc isn't so crippled ;-)
14:08 < mael> hehe
14:08 < riel> mael: I'm not sure about ia64, but to be honest I'm not very interested in ia64 either ;)
14:08 < riel> I know an ia64 won't be price effective for me, ever ;)
14:08 < eigood> riel: are you suggesting that xen will no longer support pre-pacifica in the near future?
14:08 < cdub> ia64 has similar VT tech coming down the pipeline
14:08 < mael> what do you call hypervisor interface? is it a vmx-like stuff or a wired-hypervisor?
14:09 < riel> eigood: no, those will still be supported
14:09 < mael> cdub: yeah right, vt-i/vt-x
14:09 < riel> eigood: it's just that driver domains don't make much sense on those domains, since they could still DMA over any other domain
14:09 < eigood> riel: then such support still requires xen to validate hardware programming requests, in addition to context switches when talking to other domains
14:09 < riel> eigood: no, on such an architecture you just trust your device drivers
14:10 < eigood> oh, if xen doesn't already do hardware programming verification, then remove that stmt I said
14:10 < riel> if you're paranoid enough to not trust your device drivers, you can buy a newer computer
14:10 < eigood> but inter-domain communication already requires upcalling into xen/ring0
14:10 < hollis> mael: PPC has IOMMUs, and also has processor support for hypervisors
14:10 < mael> riel: well linux device drivers at least may be critized, if you're in the real-time business for example
14:10 < eigood> maybe not on every put/get from a ring buffer, of course
14:11 < hollis> mael: if you think in terms of "rings", normal PPC has only two: user and supervisor
14:11 < mael> hollis: ok
14:11 < mael> this is a specialised instructon set then?
14:11 < hollis> mael: some PPC processors have basically added a third ring, hypervisor mode
14:11 < riel> IMHO, if you have old hardware xen should run - but if you want new fancy things, requiring hardware support isn't unreasonable
14:11 < hollis> mael: there are almost no instruction set differences
14:12 < mael> hollis: ok
14:13 < mael> what are the ppc processors you're talking about?
14:13 < mael> I guess my powerbook has only 2 rings :)
14:13 < hollis> POWER4(+), POWER5, and 970
14:13 < hollis> yup
14:13 < mael> too bad :)
14:13 < hollis> yeah
14:13 < hollis> I agree :)
14:14 < mael> shitty pile of aluminium! :)
14:14 < hollis> hey now! :)
14:15 < mael> so, pservers have the 3 rings ones?
14:15 < mael> and the new apple bi-power5 machines also
14:15 < hollis> yes, but not all pSeries. POWER3 and the RS64 processors do not have hypervisor mode
14:15 < hollis> "bi-power5" ?
14:15 < mael> ok
14:16 < mael> hold on, browsing apple website :)
14:17 < mael> hum
14:17 < mael> are G5 cpu power5 cpu?
14:18 < hollis> no. "G5" is a 970, which is based on the POWER4 but has some newer features (like from POWER5) as well
14:18 < hollis> however
14:18 < hollis> Apple has disabled 970 hypervisor mode in their firmware
14:18 < hollis> much to our dismay
14:19 < mael> what for?
14:19 < mael> it seems stupid to me
14:19 < hollis> they don't need/use it
14:19 < hollis> so I guess they'd rather not deal with it
14:19 < hollis> I don't really know why, just guessing
14:19 < mael> and you can't enable it in OF?
14:20 < hollis> no, you actually can't enable it from the 970 itself
14:20 < riel> Apple might be convinced to turn it on in future systems, at least their higher-end ones
14:20 < hollis> when I say "firmware", I mean another chip that initializes the 970
14:20 < mael> ooh
14:20 < mael> that's stupid, cos otherwiser Linus would have been very interested in porting xen mainstream :)
14:21 < mael> as he has a bi-G5 from what I heard
14:21 < hollis> he does, yeah
14:22 < mael> mmh we'll get another way ;)
14:22 < mael> and you're doing such a smart/quick job on xen that it'll be mainstream in no time
14:24  * mael is counting on vt-x on desktop machines also
14:24 < mael> this is going to bring a lot of ppl to virtualization I guess
14:24 < soffi> whatsup guys
14:24 < mael> lo soffi 
14:25 < soffi> I just got this amazing offer on managed hosting here in Iceland... It's just too tempting to rent and run some xenU's on it
14:26 < soffi> would speed up making images all the time
14:26 < mael> hehe
14:26 < mael> did you had time to look over the document I sent you?
14:27 < soffi> I thought renting hardware would be so expensive
14:27 < soffi> Yeah I glazed at it, but out CEO is in usa and I'm doing all sorts of management as well for the next week
14:27 < soffi> Lucky if I have time to eat
14:28 < mael> ok
14:28 < soffi> But I gotta go put some time into the images... at least the gentoo image... got all sorts of mails about it ;)
14:29 < soffi> mostly unpleasant ones :)
14:29 < mael> hehe
14:32 < Sir_Ahzz> so what's up guys?
14:32  * Sir_Ahzz attempts to knock some drywall dust off himself. 8-P
14:33 < mael> hi Sir_Ahzz 
14:35 < soffi> not much
14:37 < mael> well, I'm sure you all already know that SuSe pro 9.3 is out and include xen?
14:37 < Sir_Ahzz> *nod*
14:38 < soffi> did they include any tools with it ?
14:38 < soffi> y'know ?
14:38 < mael> well I don't know much
14:38 < mael> only what the website says
14:38 < soffi> I have yet to burn the live DVD iso
14:39 < mael> but I don't think they'll have vm-tools yet
14:39 < soffi> vm-tools ?
14:40 < mael> aliguori could probably inform us better on that topic
14:40 < soffi> am I dumb? what is that
14:40 < mael> aliguori's C tools
14:40 < aliguori-> soffi: vm-tools is an alterative toolchain
14:40 < mael> is in the topic ;)
14:40 < aliguori-> writting in C
14:40 < mael> hehe hello aliguori
14:40 < aliguori-> they don't (yet) support the 2.0.x tree
14:40 < aliguori-> hi mael
14:40  * Sir_Ahzz should get back to the drywalling soon since the client is paying him later today to continue work. 8-P
14:40 < aliguori-> SuSE 9.3 is based on the 2.0.x tree IIRC
14:40 < mael> mmh
14:41 < Sir_Ahzz> the toolchain definitly needs to be cluster centric IMO
14:41 < soffi> ahh,, I am dumb, I don't even know what a toolchain is
14:41 < mael> They're not very precise on that topic
14:41 < mael> they say "the latest available version" or something like that
14:42 < mael> it could be a 3.x snapshot
14:42 < mael> aliguori : btw have you read what I wrote a few hours ago?
14:42 < aliguori-> Sir_Ahzz: "cluster centric" is such a nebulus phrase
14:43 < aliguori-> mael: probably not.. my machines been crashing frequently so i don't have much history
14:43 < Sir_Ahzz> it needs to be oriented from the perspective of managing a cluster, even if that cluster is just one machine.
14:43 < mael> aliguori : ok
14:43 < Sir_Ahzz> not from the curent perspective of being a toolset for a single machine running xen domains.
14:43 < aliguori-> Sir_Ahzz: but what's different between a cluster and a network
14:44 < aliguori-> Sir_Ahzz: see, I have a slightly different approach.  I think the most important thing is that they tie in well with *existing* management tools (such as cluster management suites)
14:45 < mael> aliguori: btw I could'nt find the uclibc and busybox how to on the wiki :)
14:45 < Sir_Ahzz> I don't think any management tools really work well with the xen perspective.
14:45 < mael> but I saw you talking about ash on the chan today :)
14:45 < aliguori-> mael: of course not :-)
14:45 < aliguori-> yeah, i keep pushing it off
14:45 < Sir_Ahzz> well i'm off get more mud on myself. 8-P
14:45 < aliguori-> i'd like to wait until the next big release so that the info's up-to-date
14:45 < Sir_Ahzz> I should take pics of the closet and whatnot before it get's too far along.
14:46  * Sir_Ahzz splits for now... laters.
14:46 < aliguori-> last time i looked on the wiki, i wasn't sure where to actually put it either.. so many of the pages are read-only
14:46 < aliguori-> Sir_Ahzz: there are tons of industry management tools that already manage hypervisors..
14:46 < aliguori-> Xen is not the first hypervisor :-)
14:47 < mael> aliguori yeah that's true the wiki is mostly read only
14:47 < mael> and in the same time Ian keep on telling ppl to write stuff there ;)
14:47 < aliguori-> so i didn't see any obvious place to put a busybox howto
14:48 < aliguori-> yeah, i mean, all you can write to is the distro support page and who's doing what it seems
14:48 < aliguori-> and the faq
14:48 < aliguori-> i've never seen a wiki with so many read-only pages
14:48 < aliguori-> even wikipedia only makes the front-page read only.
14:48 < mael> well, I'll re-ask you questions related to the ressources management an other time
14:48 < eigood> said industry management tools are not free tho, right?
14:49 < aliguori-> eigood: define free
14:49 < mael> it's almost time for me to leave
14:49 < eigood> free software
14:49  * mael is heading to cambridge, uk
14:49 < eigood> DFSG
14:49 < aliguori-> eigood: nope
14:49 < eigood> mael: riding a pumpkin chucker?
14:49 < aliguori-> but i wouldn't be surprised if you started to see some
14:49 < eigood> uml has been around for a bit; now with uml, we can hope to see a standard emerge
14:50 < eigood> s/with uml/with xen/
14:50 < aliguori-> in the past, there's been no reason to has foss tools for properitary hardware :-)
15:04 -!- mael [~mael@kali.tirnamban.org] has quit [Quit: Leaving]
15:07 < hollis> joining the conversation late... how is UML managed?
15:08 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
15:12 < eigood> there are some tools for it; we stopped using uml(and switched to xen, yay!) before we started looking at management tools for it
15:13 < hollis> how about creating a UML "domain" (instance? what do you call it?)? starting it, stopping it, provisioning it?
15:13 -!- alx_ [foobar@213-152-38-2.dsl.eclipse.net.uk] has joined #xen
15:14 < aliguori-> hollis: uml is just a process in linux
15:15 < aliguori-> you run it like a process and pass the configuration for it on the command line
15:15 -!- tab [~tab@darwin.snarc.org] has quit [Ping timeout: 480 seconds]
15:15 < aliguori-> i guess you could nice it to do some resource control but i've never tried.
15:16 < aliguori-> uml is kind of strange because it doesn't have a real scheduler.  processes within a uml image are scheduled by the hosts scheduler
15:18 < eigood> aliguori-: your wrong
15:18 < aliguori-> eigood: about what?
15:18 < eigood> it not having a scheduler
15:18 < eigood> it's always had one
15:19 -!- tab [~tab@darwin.snarc.org] has joined #xen
15:20 < eigood> where is space and enter?
15:20 < caker> next to the any key
15:21 < aliguori-> eigood: my understand of uml is that each process in a uml guest is also a process in the host
15:22 < aliguori-> eigood: uml decides which one goes next but the host decides when it goes next
15:22 < aliguori-> so it's not a real scheduler
15:23 < aliguori-> i'm having trouble finding a paper about it
15:23 < aliguori-> i could be wrong
15:23 < eigood> not quite
15:23 < caker> SKAS mode works differently, but it's the same deal -- the host distributes CPU time to UML, and UML uses Linux's scheduler
15:23 < aliguori-> i read the uml papers a few years ago
15:23 < eigood> uml straces everything.  so the host can only schedule the host-based process is not STOP'd waiting on uml to do it's magic
15:23 < eigood> then, with skas, things are a bit more complex
15:24 < caker> Jeff recently virtualized the Linux scheduler -> http://user-mode-linux.sourceforge.net/diary.html
15:25 < aliguori-> ah, this is interesting
15:25 < aliguori-> this solves the problem i was alluding to quite nicely
15:25 < aliguori-> that resource control is difficult in uml.
15:26 < aliguori-> i saw that someone is giving a talk at ols about extending uml to run in ring 0 with the vmx extensions
15:32 < eigood> hmm, lots of cool stuff on that diary
17:17 -!- N [~ca4bc809@webuser.thegrebs.com] has quit [Quit: http://thegrebs.com/oftc/ (Session timeout)]
17:43 -!- riel is now known as unriel
17:50 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
18:00 -!- deac [~deac@xdsl-81-173-137-130.netcologne.de] has quit [Ping timeout: 480 seconds]
18:04 -!- yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has quit [Quit: Leaving]
18:12 -!- deac [~deac@xdsl-84-44-214-81.netcologne.de] has joined #xen
18:26 -!- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Read error: Operation timed out]
18:28 -!- unriel [~riel@nat-pool-bos.redhat.com] has quit [Read error: Operation timed out]
18:36 -!- yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has joined #xen
19:09 -!- yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has quit [Quit: Leaving]
19:17 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
19:34 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:35 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
20:16 -!- tierra|w_ [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
20:16 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Read error: Connection reset by peer]
20:17 -!- tierra|w_ is now known as tierra
20:21 -!- tab [~tab@darwin.snarc.org] has quit [Remote host closed the connection]
20:21 -!- tab [~tab@81.56.210.228] has joined #xen
20:25 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
20:35 -!- tab [~tab@81.56.210.228] has quit [Ping timeout: 480 seconds]
20:40 -!- tab [~tab@darwin.snarc.org] has joined #xen
21:21 -!- joink_ [~joink@186.80-202-132.nextgentel.com] has joined #xen
21:23 -!- joink [~joink@186.80-202-132.nextgentel.com] has quit [Ping timeout: 480 seconds]
21:34 -!- knewt [~jmb@zeus.pimb.org] has quit [Ping timeout: 480 seconds]
21:44 -!- drbyte [~byte@150.203.247.9] has joined #xen
21:45 -!- joink_ is now known as joink
21:55 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
22:04 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
22:07 -!- drbyte [~byte@150.203.247.9] has quit [Quit: Leaving]
22:38 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
22:49 -!- drbyte [~byte@150.203.247.9] has joined #xen
22:50 -!- knewt [~jmb@zeus.pimb.org] has quit [Quit: hateful reboot]
22:51 -!- drbyte [~byte@150.203.247.9] has quit [Quit: ]
22:52 -!- drbyte [~byte@150.203.247.9] has joined #xen
23:18 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
23:29 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
23:32 -!- knewt [~jmb@zeus.pimb.org] has quit [Remote host closed the connection]
23:32 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
23:47 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: Everybody wants to go to heaven, but nobody wants to die.]
--- Log closed Wed Apr 20 23:59:00 2005