TheGrebs.com:IRC Logs:#xen:2006:03:12

---	Log	opened Sun Mar 12 00:00:23 2006
00:01	\|-\|	hikenboot [~hikenboot@c-24-218-84-234.hsd1.ma.comcast.net] has quit [Quit: Leaving]
00:20	\|-\|	surriel [~riel@fangorn.surriel.com] has joined #xen
01:09	\|-\|	Dave` [~dave@natulte.net] has left #xen []
01:21	\|-\|	horms [~horms@p2191-ipbf409marunouchi.tokyo.ocn.ne.jp] has left #xen [Leaving]
01:36	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
02:08	\|-\|	zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Remote host closed the connection]
03:07	\|-\|	DV [~veillard@veillard.com] has joined #xen
04:29	\|-\|	jesse_ [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
04:30	\|-\|	jesse_ changed nick to wenchien
06:27	\|-\|	Trnc [~spam@l192-117-117-32.broadband.actcom.net.il] has joined #xen
06:33	\|-\|	rusty [~rusty@ppp61-206.lns1.cbr1.internode.on.net] has quit [Quit: Client exiting]
07:09	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
07:38	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
07:46	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
07:48	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Remote host closed the connection]
07:58	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
08:25	\|-\|	felix [~felix@CPE001346d29ce3-CM00e06f1ae0c4.cpe.net.cable.rogers.com] has joined #xen
08:45	\|-\|	pvanhoof [~pvanhoof@d54C0E27E.access.telenet.be] has joined #xen
09:01	\|-\|	felix [~felix@CPE001346d29ce3-CM00e06f1ae0c4.cpe.net.cable.rogers.com] has quit [Quit: Client exiting]
09:55	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
09:59	\|-\|	zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
10:01	\|-\|	michal` [~michal@www.rsbac.org] has quit [Ping timeout: 480 seconds]
10:06	\|-\|	michal` [~michal@www.rsbac.org] has joined #xen
11:03	\|-\|	surriel [~riel@fangorn.surriel.com] has quit [Ping timeout: 480 seconds]
11:42	\|-\|	zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Quit: Leaving]
11:54	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has quit [Remote host closed the connection]
11:57	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has joined #xen
12:36	\|-\|	Shaun2222 [~ndci@ip68-5-63-223.oc.oc.cox.net] has joined #xen
12:43	\|-\|	Shaun [~ndci@ip68-5-63-223.oc.oc.cox.net] has quit [Ping timeout: 480 seconds]
12:44	\|-\|	Shaun2222 changed nick to Shaun
12:49	\|-\|	tab_ [~tab@darwin.snarc.org] has quit [Remote host closed the connection]
13:06	\|-\|	pvanhoof [~pvanhoof@d54C0E27E.access.telenet.be] has quit [Ping timeout: 480 seconds]
13:21	\|-\|	dhendrix [~dhendrix@c-69-247-65-201.hsd1.nm.comcast.net] has quit [Quit: Leaving]
13:29	\|-\|	dhendrix [~dhendrix@c-69-247-65-201.hsd1.nm.comcast.net] has joined #xen
13:30	\|-\|	rtotheg [~rpg@cpe-72-177-84-209.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
13:34	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Client exiting]
13:39	\|-\|	rtotheg [~rpg@cpe-72-177-84-209.austin.res.rr.com] has joined #xen
13:46	\|-\|	tarawa [~tarawa@c-67-169-198-176.hsd1.or.comcast.net] has joined #xen
13:58	<aliguori>	DV: ping?
13:58	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
13:59	<aliguori>	oh, i see you replied :-)
14:26	<DV>	aliguori: pong
14:26	<DV>	yeah, a bit puzzled, maybe I misunderstood :-)
14:28	<aliguori>	DV: okay, I just posted a response with a more detailed explaination.. sorry, sometimes I don't necessarily explain myself well :-)
14:29	<DV>	No new messages , didn't get it yet :-)
14:29	<aliguori>	DV: that's b/c i literally just hit send ;-)
14:32	<DV>	now I can time that mailing-list
14:32	<DV>	and I'm probably at the end
14:32	<aliguori>	:-)
14:32	<aliguori>	well, i sent it via gmane
14:33	<aliguori>	so it might have some lag...
14:33	<aliguori>	DV: basically, the idea is to have a separate program act as an XML-RPC that enforces some sort of policy based on the current user
14:34	<aliguori>	DV: and then use SSH as a transport to handle authentication/privacy. for the localhost case, SSH is unnecessary (you can instead just invoke the proxy directly)
14:34	<aliguori>	the proxy would be suid
14:35	<DV>	so basically you don't want to integrate authentication
14:35	<aliguori>	no
14:35	<aliguori>	b/c to do it right, you need to use PAM
14:35	<aliguori>	and you need to worry about privacy
14:35	<aliguori>	having a password database will not scale to enterprise environments that have password update policies and such
14:36	<aliguori>	it's important to tie into enterprise-identity systems
14:37	<DV>	I didn't say passwd database
14:37	<aliguori>	yeah, I know :-)
14:37	<DV>	you can design a protocol to handle authentication
14:37	<DV>	without providing the mean for that authentication
14:37	<aliguori>	DV: what do you mean?
14:38	<DV>	http auth
14:38	\|-\|	tonyb_ changed nick to tonyb
14:38	<aliguori>	DV: oh, but to do http, you need to use SSL right?
14:38	<aliguori>	b/c sending root password plain text over the wire is not okay :-)
14:38	<aliguori>	but to use SSL, you need to do certificate verification
14:38	<DV>	depends the kind of authentication you're using
14:39	<aliguori>	DV: if you are going to authenticate with PAM, you have to use basic auth (or install a special PAM plugin to generate the DIGEST hash at login time)
14:39	<DV>	most of the time you hash against key and never carry the passwd
14:40	<DV>	I'm stating the fact you can design or reuse protocols where the mechanism for auth is not cast in stone
14:40	<aliguori>	and even plain-text digest is worry-some. it's still suspectible to man-in-the-middle attacks and even brute force attacks depending on which has you use
14:40	<DV>	and you're replying "I want to use PAM" which for me is such a mechanism
14:41	<aliguori>	yeah, I'm using PAM as an example b/c it has the requirement of needing the plain-text password. i mean, i guess one could use tls or something like that
14:41	<aliguori>	i dunno if there's been any work on http tls
14:42	<aliguori>	there's an RFC apparently :-)
14:42	<DV>	to me a domain should have an owner
14:43	<DV>	and there should be a pluggable way to authenticate the owner
14:43	<DV>	at the moment I'm seeing thing like live migration where I don't see how authentication is done
14:43	<aliguori>	DV: it's not
14:43	<DV>	I see we are designing RPC APIs but also dropping authentication
14:43	<aliguori>	DV: but that's a separate problem :-)
14:44	<aliguori>	DV: no, i'm assuming an authenticated transport
14:44	<DV>	and I'm getting really worried
14:45	[~]	DV got a new email from Kurt Garloff on the list but not yours
14:45	<aliguori>	ok,one sec
14:45	<DV>	well anyway you probably just explained the same
14:47	\|-\|	tarawa [~tarawa@c-67-169-198-176.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds]
14:50	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
14:50	<aliguori>	DV: well, I just fwd'd it to you directly. the email has a much better explaination as it goes into gory detail about how it ought to work
14:50	<aliguori>	DV: i actually think we're advocating the same thing, I just think i'm doing a poor job of explaining it ;-)
14:50	[~]	aliguori attributes it to the heat
14:50	<aliguori>	:-)
14:50	<DV>	what worries me is that your solution is not integarted
14:51	<DV>	maybe it's actually a feature
14:51	<aliguori>	yes
14:51	<DV>	but that mean that we don't think about it
14:51	<DV>	from a design standpoint
14:51	<aliguori>	so, it's really identical to yours, except that it's a separate program than Xend
14:51	<DV>	and I don't want to let this go without triple checking
14:52	<aliguori>	well, I actually think keeping it a separate program helps the security b/c it makes the code more auditable
14:52	<aliguori>	i really wouldn't trust authentication code in xend at all
14:52	<aliguori>	it's too complex right now and i certainly don't feel like i completely have my head around it
14:53	[~]	DV think he can kiss the idea of a Xen applet goodbye
14:53	<aliguori>	heh, why?
14:54	<DV>	because I really don't see how you're gonna do it
14:54	<aliguori>	so XML-RPC over TCP is going to be supported for 3.0.2. i'm committed to not break lesser-user management too
14:55	<aliguori>	so that should be out there first just as a baseline
14:55	<aliguori>	and like S-Expression/HTTP, XML-RPC over domain socket will be the default but xend-config.sxp can be modified to enable TCP
14:56	<aliguori>	but what I'm proposing we do, is get rid of TCP altogether in the future, and instead implement an SUID program called xend-remote proxies between stdio and the Xend XML-RPC domain socket
14:56	<DV>	yeah, and each time the applet refresh the list you get 4 context switch
14:56	<aliguori>	In the simpliest case, xend-remote reads a config file that is a white list of which calls are allowed by what user, and if a user attempts to make an unallowed call, returns a 401
14:57	<aliguori>	on the x86 a context switch is only ~500 cycles
14:57	<aliguori>	which is roughly 10 divides
14:57	<aliguori>	it's really not that bad
14:57	<DV>	the cost is in context and cache destruction
14:58	<aliguori>	yes, but really, is this a performance critical issue?
14:58	<DV>	then we heard that the desktop is bloated
14:59	<aliguori>	we're only talking about doing one more level of proxying.. compared to something like dbus, it's nothing
14:59	<DV>	nothing is performance critical, but everything adds up
14:59	<aliguori>	i'm sure the applet is going to be using gconf too
14:59	<aliguori>	which is just as bad
14:59	<aliguori>	sure, but the cost here is neglible IMHO compared to the other costs in this path
15:00	<DV>	I still find nasty that the API being exported is not what you can use
15:01	<aliguori>	DV: well, it really just depends on how much you're bothered by having the policy stuff be a separate process. If it were in Xend, it'd likely be a separate thread anyway
15:03	<aliguori>	DV: well, for the near term, we've still got the TCP stuff. For the long term, it's my responsibility to convince you that this really isn't a bad approach. :-) so no worries, I'll eventually code up some stuff, and if noone likes it, it doesn't go in
15:06	<DV>	maybe I need sleep
15:07	<DV>	but this exec/stdio sounds messy ATM
15:08	<DV>	I was already worried because we were creating a new connection each and every time
15:08	<DV>	not it looks like fork/exec/auth for each probe
15:09	<DV>	we use XML-RPC over SSL with auth for RHN
15:09	<DV>	and with persistent connections, I don't see how with HTTP/1.1 this can't be done
15:10	<DV>	s/not/now/
15:10	<aliguori>	DV: it could. but I think the server side certificate stuff is going to turn out to be nasty
15:10	<aliguori>	RHN only has one (or at least) a fixed set of servers
15:10	<aliguori>	and RH can buy certs for them
15:11	<aliguori>	but if Xend now has to have a cert... i mean, we could just use snake oil ones but I think that would make at least some of our customers nervous
15:11	<aliguori>	a large scale certificate management (to deal with expired certs) is a PITA
15:11	<aliguori>	s/a/and/
15:12	<DV>	we don't need certificate per see
15:12	<DV>	we need priviledge though local unix socket
15:13	<aliguori>	okay, well, perhaps there's a compromise here then
15:13	<aliguori>	i still think we ought to have a read-only socket equivalent
15:13	<DV>	yes that is clear for operations without side effects
15:13	<aliguori>	so, i think exposing read-only rpc calls over a lesser privileged socket would be a good thing
15:14	<aliguori>	i think for a more sophisticated policy-based mechanism, we need an SUID helper
15:14	<aliguori>	b/c i want to keep that code out of Xend
15:14	<DV>	don't make architecture design because you don't trust a current state of the code
15:15	<aliguori>	it's not
15:15	<DV>	I understand taht separation may be a very good thing
15:15	<aliguori>	Xend is a daemon.. I think it should only provide services that require state.. policy enforcement doesn't require state
15:16	<DV>	the more I think about it the more I believe that only a capacity like system is adequate
15:17	<DV>	to create a domain you need hypervisor capacity
15:17	<DV>	one create tou get a capacity for that domain
15:17	<DV>	you migrate it you need the capacity on both side
15:17	<DV>	etc ...
15:19	<DV>	you need the domain capacity to pause/resume it
15:19	<DV>	you need the hypervisor capacity to change the number of CPU or scheduling or baloon
15:20	<DV>	and some operations don't need any like listing the state
15:21	<DV>	I doubt PAM would fit well there, maybe I'm out of scope
15:24	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
15:31	\|-\|	jdmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
15:36	\|-\|	zwane [~zwane@24.85.128.227] has joined #xen
15:37	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
15:37	<aliguori>	doh, didn't realize i got booted offline there
15:39	<iamlost>	aliguori: :)
15:39	<iamlost>	aliguori: i'm trying to get the nvidia binary drivers to work under xen
15:40	<iamlost>	i found an email refering to a agp.patch in an older xen tree (in order to help one get started) but i cant seem to find it anywhere
15:40	<aliguori>	iamlost, yikes
15:41	<jdmason>	plaease don't taint the xen kernel with binary drivers
15:42	<aliguori>	heh
15:42	<aliguori>	jdmason, jacob got the ati binary drivers working under xen...
15:43	<iamlost>	jdmason: i'm taintint the dom0 kernel, not the xen kernel
15:43	<jdmason>	aliguori: can't samrt ppl like jacob find better things to work on?
15:43	<iamlost>	aliguori: yes, i read abt that ... thats what inspired me in fact :)
15:43	<aliguori>	iamlost, jdmason is just being difficult :-)
15:43	<jdmason>	aliguori: me?
15:44	<iamlost>	i also read that the nvidia developer team for linux is working on a xen port w/o a definite time table
15:44	<aliguori>	jdmason, yeah, you, difficult, strange, it's not in your nature at all ;-)
15:44	<iamlost>	but im far too impatient to wait for them ;)
15:44	<jdmason>	iamlost: maybe you can get a bounty from them :)
15:45	[~]	aliguori wonders if we can export_gpl all of the xen interfaces.. that would rock
15:45	<iamlost>	heh
15:45	<tonfa>	:)
15:46	<iamlost>	aliguori: http://lists.xensource.com/archives/html/xen-devel/2005-02/msg00329.html
15:46	<tonfa>	aliguori: but you should remove the userspace dom0 no ?
15:46	<jdmason>	aliguori: do it, though I think xensource has the opposite idea in mind
15:47	<aliguori>	iamlost, yeah, jacob was demo'ing his opengl stuff at the recent xensummit
15:47	\|-\|	michal` [~michal@www.rsbac.org] has quit [Ping timeout: 480 seconds]
15:47	<aliguori>	tonfa, i'm not sure i understand your comment
15:47	<iamlost>	aliguori: of course somehow i get the feeling that is not the complete patch...
15:47	<tonfa>	aliguori: what do you mean by xen interfaces ?
15:47	<aliguori>	tonfa, oh, i meant the kernel interfaces :-)
15:48	<aliguori>	to keep people from porting binary modules to a xen kernel :-)
15:48	<tonfa>	for me it looks like a lot of it is exported to userspace
15:48	<aliguori>	to help quicken the pace at which binary kernel modules go away
15:48	<iamlost>	iirc Nvidia is opensourcing its Xgl implementation anyways
15:50	<iamlost>	but again, i'm too impatient to wait O:)
15:52	<jdmason>	iamlost: that would require the nvidia binary kernel module, yes?
15:53	<iamlost>	jdmason: iiuc the full driver was being opensourced...
15:53	<jdmason>	iamlost: if so, I will be greatly impressed
15:53	<iamlost>	tho the kernel module wasnt actually mentioned, so i might be wrong there.
15:54	<jdmason>	nvidia has been acting better
15:54	<DV>	aliguori: got your message 3 times now
15:54	<jdmason>	I hope it means they understand opensource now
15:54	<DV>	aliguori: I was afraid I had bored you
15:55	<DV>	aliguori: I sent my crazy model of all this on the list, maybe if I get beaten up long enough I will start thinking in a more normal way :-)
16:22	\|-\|	Trnc [~spam@l192-117-117-32.broadband.actcom.net.il] has quit [Quit: ]
16:22	<aliguori>	DV, heh, oops, sorry about that :-)
16:23	<DV>	about what ?
16:23	<aliguori>	DV: 3 copies of the message :-)
16:23	<DV>	oh, no problem :-)
16:24	<DV>	they arrived more or less at the same time, maybe redhat.com mail processing was a bit slow
16:34	\|-\|	zwane [~zwane@24.85.128.227] has quit [Read error: Connection reset by peer]
16:48	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Quit: Ex-Chat]
16:51	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
16:55	<DV>	wb
16:57	\|-\|	tarawa [~tarawa@c-67-169-198-176.hsd1.or.comcast.net] has joined #xen
16:58	[~]	iamlost hugs aliguori
17:01	[~]	iamlost gives up on getting the pc speaker to work under xen
17:01	<aliguori>	dah
17:01	[~]	aliguori feels slightly uncomfortable
17:01	<aliguori>	:-)
17:04	\|-\|	zwane [~zwane@24.85.128.227] has joined #xen
17:14	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
17:15	<iamlost>	does something in xen intefere with the pc speaker?
17:34	<aliguori>	iamlost, not that i know of
17:34	<iamlost>	maybe my kernel is borked then?
17:34	<iamlost>	its a multidom with devfs compiled in
17:34	<aliguori>	yikes
17:34	<aliguori>	devfs?
17:34	<iamlost>	yes
17:35	<iamlost>	hence, it only works as a dom0, despite being multidom... :(
17:39	<iamlost>	the other thing i've noticed with xen is that it makes my disk and my fan quieter :)
17:39	<iamlost>	but that i am in no hurry to change :)
17:40	<tarawa>	dykman, ping?
17:43	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
17:50	\|-\|	michal` [~michal@www.rsbac.org] has joined #xen
18:45	\|-\|	horms [~horms@vagw.valinux.co.jp] has joined #xen
18:51	\|-\|	JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has quit [Quit: I don't want to see any pineapple in my anus.]
18:54	\|-\|	surriel [~riel@fangorn.surriel.com] has joined #xen
18:54	\|-\|	surriel changed nick to riel
19:04	\|-\|	riel [~riel@fangorn.surriel.com] has quit [Read error: Connection reset by peer]
19:05	\|-\|	JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has joined #xen
19:05	\|-\|	zwane [~zwane@24.85.128.227] has quit [Quit: Leaving]
19:15	\|-\|	surriel [~riel@fangorn.surriel.com] has joined #xen
19:15	\|-\|	surriel changed nick to riel
19:50	\|-\|	JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has quit [Ping timeout: 480 seconds]
19:51	\|-\|	JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has joined #xen
19:55	\|-\|	zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
20:05	\|-\|	muli_ [~muli@87.69.40.180.cable.012.net.il] has quit [Ping timeout: 480 seconds]
20:05	\|-\|	muli_ [~muli@87.69.40.180.cable.012.net.il] has joined #xen
20:22	\|-\|	tarawa [~tarawa@c-67-169-198-176.hsd1.or.comcast.net] has quit [Quit: Leaving]
20:28	<iamlost>	do i need to do anything special for virt_to_page() ?
20:28	<iamlost>	or __va() ?
20:28	\|-\|	womble [~mpalmer@sponge.solutionsfirst.com.au] has joined #xen
20:45	\|-\|	riel [~riel@fangorn.surriel.com] has quit [Ping timeout: 480 seconds]
20:50	\|-\|	surriel [~riel@fangorn.surriel.com] has joined #xen
21:00	\|-\|	yorkedork [~thom@softbank218176034086.bbtec.net] has joined #xen
21:01	\|-\|	yorkedork [~thom@softbank218176034086.bbtec.net] has quit [Quit: ]
21:02	<iamlost>	nice
21:02	<iamlost>	http://zaitcev.livejournal.com/53104.html
21:42	\|-\|	surriel changed nick to riel
21:45	<aliguori>	iamlost, yeah, i think most people have that reaction. i'm growing ever more certain that the push upstream is going to be very difficult
21:47	<johnlev>	it's always seemed a bit of a weird naming convention to me :)
21:48	<aliguori>	someone had made a comment about not trying to reuse the xen public headers for Linux and instead write custom Linux headers that actually followed the linux CodingStyle..
21:48	<aliguori>	and there's always vmi too...
21:48	<aliguori>	or at least something a bit more well-defined
21:50	<johnlev>	hrm, then what happens to the public headers
21:52	<aliguori>	it's kind of odd for Linux to depend on external headers...
21:52	<johnlev>	for an external hypervisor?
21:52	<aliguori>	sure
21:53	<johnlev>	we have two copies of all the interfaces then.
21:53	<johnlev>	(two divergent copies, that is)
21:53	<aliguori>	I hope not
21:53	<aliguori>	that means guests break :-)
21:54	<johnlev>	IDGI then
21:56	<riel>	nothing wrong with a big code cleanup
21:56	<riel>	Xen could use it
21:56	<johnlev>	I was never clear why Xen chose to differ from the linux coding style anyway, given how much code is borrowed
21:57	<aliguori>	yeah, I don't understand either.
21:57	<johnlev>	but I don't understand how having one version of the headers in linux and one in xen is a good idea.
22:01	<aliguori>	well, considering the current xen hypercall interface, yeah, it would be mad to try and maintain two versions. if xen adopted a more sane one that more closely resembled hardware and was likely to stay fixed for many years to come, i don't think it would be unreasonable
22:01	<aliguori>	ideally, a hypervisor's interface ought to be as well defined as a hardware interface i reckon
22:01	<johnlev>	fair enough.
22:01	<johnlev>	aliguori: some way to go yet ;)
22:02	<aliguori>	heh, yeah, definitely :-)
22:11	\|-\|	tarawa [~tarawa@c-67-169-198-176.hsd1.or.comcast.net] has joined #xen
22:11	<tarawa>	aliguori, ping?
22:12	<riel>	yes, hypervisor interfaces absolutely need to be stable
22:12	<riel>	otherwise it'll be impossible to run Linux version N and version N+2 on the same hypervisor
22:15	\|-\|	tarawa changed nick to woody_home
22:16	<woody_home>	aliguori, on ubuntu have you had problems with the AM_LOCAL macros in xm-test?
22:22	<aliguori>	woody_home, no, they aren't new are they?
22:22	<aliguori>	riel, 100% agreed
22:23	<aliguori>	woody_home, i'll try tip right now with two ubuntu boxes
22:23	<movement>	riel: or sufficiently versioned where that makes sense
22:24	<aliguori>	woody_home, hrm, AM_LOCAL doesn't appear to occur at all in the xm-test in tip
22:25	<woody_home>	aliguori, if pull xm-test then autogen/configure, I get an XFAIL macro err
22:25	<woody_home>	aliguori, had to add AM_LOCAL instead of AC_LOCAL
22:26	<aliguori>	woody_home, in what file?
22:26	<woody_home>	aliguori, it seems to be with the m4 I have on 5.11
22:26	<woody_home>	aliguori, Makefile.am
22:26	<woody_home>	aliguori, let me chk again
22:27	<aliguori>	i have neither AM_LOCAL or AC_LOCAL in any of my Makefile.am 's...
22:27	<woody_home>	aliguori, opps
22:28	<woody_home>	aliguori, 1 min
22:28	<aliguori>	k
22:28	<woody_home>	aliguori, configure.ac: 61: automake requires `AM_PROG_LEX', not `AC_PROG_LEX'
22:29	<woody_home>	aliguori, automake I can chg it but get the XFAIL not define
22:29	<riel>	Xen just shows how much difference there can be between a research project and a production system
22:30	<aliguori>	woody_home, i may have a newer version of automake or something... honestly, i'm not very much up with the autotools vodoo.
22:30	<woody_home>	aliguori, me 2
22:30	<woody_home>	aliguori, it must be in m4 but you can build xmtest ok?
22:30	<aliguori>	riel, i will say, i've notice a dramatic change in the cambridge folks in the past 6 months.. i think they're starting to understand that
22:30	<aliguori>	i've been more optimistic lately
22:30	<aliguori>	woody_home, yup
22:30	<woody_home>	aliguori, thx
22:31	<aliguori>	woody_home, np, sorry i couldn't be more useful :-/
22:31	<movement>	riel: we should all get tattoos or something
22:31	<woody_home>	aliguori, u r the man! :)
22:31	<riel>	aliguori: yeah, things have definately been improving
22:31	[~]	aliguori is happy to finally have a shirt
22:31	<aliguori>	:-)
22:32	<movement>	heh
22:32	<aliguori>	there's not nearly enough xen swag :-)
22:37	[~]	iamlost gets a headache from trying to figure out how xen agp works
22:41	\|-\|	woody_home [~tarawa@c-67-169-198-176.hsd1.or.comcast.net] has quit [Remote host closed the connection]
22:49	<iamlost>	there should be a guide somehwere
22:49	<iamlost>	"how to port device drivers to xen"
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has left #xen [Rotating Logs]
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has joined #xen
23:07	\|-\|	knewt_ [jmb@home.pimb.org] has joined #xen
23:07	\|-\|	knewt [jmb@home.pimb.org] has quit [Read error: Connection reset by peer]
23:07	\|-\|	knewt_ changed nick to knewt
23:07	\|-\|	knewt changed nick to Guest3065
23:09	\|-\|	Guest3065 [jmb@home.pimb.org] has quit [Quit: ]
23:09	\|-\|	knewt [jmb@home.pimb.org] has joined #xen
23:53	\|-\|	Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has quit [Quit: foo]
---	Log	closed Mon Mar 13 00:00:16 2006