TheGrebs.com:IRC Logs:#xen:2005:03:31

---	Log	opened Thu Mar 31 00:00:50 2005
00:35		* riel starts AIM7 on a "3 CPU" xenU guest
00:37	caker	Is it the unstable branch that has support for MP guests?
00:38	@riel	yes
00:38	caker	wow.. What's the status? Fairly stable at this point?
00:40	@riel	it often is
00:41	@riel	I think I ran into a little smp bug in page table handling
00:41	@riel	I'll send a patch to xen-devel tomorrow, for discussion
00:41		* riel zzzzzzz
00:41	@riel	really time to sleep now ;)
00:41	@riel	aim7 will run by itself just fine
01:23	@riel	ok, aim7 is chugging along nicely
01:23	@riel	this is pretty cool
02:24	---	<<-- cw [cw@adsl-67-124-117-212.dsl.snfc21.pacbell.net] has quit (Ping timeout: 480 seconds)
02:28	---	---> cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has joined #xen
03:09	---	<<-- rusty [~rusty@bh02i525f01.au.ibm.com] has quit (Quit: Client exiting)
04:06	---	---> LaidBack_01 [~jax@69.146.20.246] has joined #xen
04:13	---	---> Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
05:08	---	<<-- muli [~muli@alhambra.mulix.org] has quit (Ping timeout: 480 seconds)
---	Log	opened Thu Mar 31 13:24:28 2005
13:24	---	---> mikegrb [~michael@thegrebs.com] has joined #xen
13:24	-!-	Irssi: #xen: Total of 37 nicks 2 ops, 0 halfops, 0 voices, 35 normal
13:25	-!-	Irssi: Channel: Join to #xen was synced in 90 secs
13:28	---	---> Beirdo_ [~gjhurlbu@linode.beirdo.ca] has joined #xen
13:28	---	---> anthill333 [~larsr@palwebproxy1.core.hp.com] has joined #xen
13:34	---	User: *** Beirdo_ is now known as Beirdo
13:46	---	<<-- anthill333 [~larsr@palwebproxy1.core.hp.com] has quit (Remote host closed the connection)
13:58	---	<<-- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit (Ping timeout: 480 seconds)
14:02	---	---> greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
14:16	---	---> VS_ChanLog [~stats@ns.theshore.net] has joined #xen
14:32	@riel	hummm, big interdiff
14:32		* riel reads
14:32	---	---> totempole [~chatzilla@lawn-199-77-210-154.lawn.gatech.edu] has joined #xen
14:33	---	<<-- totempole [~chatzilla@lawn-199-77-210-154.lawn.gatech.edu] has quit (Quit: )
14:33	@riel	it might be later tonight before I upgrade the xen code in rawhide ;)
14:33	@riel	almost 5000 lines of patch to go through
14:34	@riel	luckily most of it seems to be the removal of the batched pagetable updates, so that's easy
14:35	---	---> niv [~niv@bi01p1.co.us.ibm.com] has joined #xen
14:37	rocket	I am interested in getting an understanding of xen and kernel internals and things like that is there anywhere you guys suggest I start looking for information to get up to speed?
14:38	---	---> caker [~caker@ns.theshore.net] has joined #xen
14:38	hollis	rocket: have a look at the papers on the Xen website
14:39	rocket	hollis: sounds good .. and for the kernel internals, etc? is there a good book to read? online docs?
14:39	@riel	Understanding The Linux Kernel
14:39	rocket	riel: I am assuming thats a book title
14:39	@riel	yeah, it is
14:40	rocket	ok
14:40	rocket	sorry I am such a newbie in this area .. its just something I have always been interested in .. and need to find a place to start :p
14:46	@riel	do you know what syscalls are ?
14:46	@riel	xenolinux makes "hypercalls" into xen - very similar to syscalls
14:47	LaidBack_01	hey, everytime I try to get xen 2.0.5 to work, my kernel hangs.
14:47	LaidBack_01	now 2.0.4 worked fine.
14:47	LaidBack_01	anyone else run into issues similar?
14:47	rocket	yeah .. I have a rudimentary understanding of syscalls ..
14:47	LaidBack_01	I've read the mailing list on this, but only one other had the problem it seemed.
14:48	rocket	riel: "understanding the linux kernel" is kind of old is that ok?
14:48	@riel	it explains the concepts behind the code
14:48	@riel	instead of just explaining the code
14:49	rocket	ah ok .. thats better anyway :p
14:49	@riel	if you want a nice explanation of the code, and don't need an explanation of the concepts behind it, Robert Love's book is great
14:49	@riel	but if you're new to OS hacking, you may want a book with a bit more background info
14:49	rocket	probably want the background info .. :p
14:50	rocket	and do these books cover the assembly parts very much?
14:52	@riel	only a little bit, I think
14:54	rocket	ok
14:54		* rocket is attempting to get grsecurity working with xen .. but knows at the moment I am out of my league :/
14:58	---	<<-- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit (Read error: Operation timed out)
15:01	@riel	rocket: why?
15:01	rocket	why am I out of my league or why am I trying to get grsecurity working?
15:02	@riel	why are you trying to get grsecurity working ?
15:02	@riel	and, which parts ? ;)
15:02	@riel	if you get stuck on PaX, you can just take the execshield patches from fedora rawhide
15:03	rocket	well mostly the acl's and process listing parts ..
15:03	rocket	but I thought it would be cool to have grsecurity enabled xen kernels .. to build more secure firewall xen instances etc
15:05	rocket	I was trying to look at the grsecurity patch and just grab the i386 arch specific stuff and apply it to the xen arch .. but there are some files missing/changed that I dont understand what I need to do .. so I know I need a better understanding of the kernel
15:05	rocket	basically its a pet project to learn OS hacking better :)
15:06	@riel	you can do much better than that
15:06	@riel	run a bridging firewall, without any IP addresses at all
15:06	@riel	access it via the xen console
15:06	---	---> greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
15:07	rocket	yeah I know I can do that .. but i was also thinking of more secure dns/web/mail server instances .. etc .. since I dont have a ton of hardware .. I like the virtualization concepts ..
15:07	knewt	is acpi support in -unstable yet? it's that that's stopping me from putting it on my laptop
15:10	@riel	rocket: there's no security like read only filesystems, enforced by the hypervisor ;)
15:11	@riel	rocket: ideally even a kernel exploit should not compromise the virtual machine's most important things
15:11	rocket	riel: true :)
15:13	rocket	but when you get into needing rw filesystems etc or giving greater control .. there are some nice features in grsecurity .. and again it is a pet project ..
15:13	@riel	it'll be a good learning experience, true
15:13	@riel	so you should probably try porting it
15:14	jeroney	rocket: this is RBAC just use SELinux and do MAC
15:14	jeroney	rocket: you can get the same effect
15:15	rocket	jeroney: I dont doubt that one bit .. in fact I totally agree .. but i want to learn how to do it .. if that makes sense?
15:16	@riel	rocket: you may want to talk with some of the people on #kernelnewbies
15:16	@riel	they're doing similar projects
15:16	jeroney	hmm...well I would say start with the books, and a couple months from now you'll be be able to just jump into it...I would start by writing an LSM for the kernel
15:16	rocket	ok
15:17	rocket	jeroney: sounds good
15:23	eigood	ladbac: well, considering you haven't told us anything
15:23	---	---> Surferdude [~Surferdud@pcp08365167pcs.lndsd201.pa.comcast.net] has joined #xen
15:23	eigood	LaidBack_01: well, considering you haven't told us anything
15:24	---	<--- Surferdude [~Surferdud@pcp08365167pcs.lndsd201.pa.comcast.net] has left #xen ()
15:24	eigood	riel: I've got a new dbs-ng(patch management tool used by several debian packageS) that makes upgrading to new upstreams fairly easy
15:25	eigood	it's destined to become dpkg-source v2, once I finish rewriting it from perl to c
15:25	eigood	</pimp>
15:25	@riel	eigood: oh, applying patches isn't the problem
15:25	@riel	eigood: I just read the patch to make sure the content doesn't conflict with eg. my execshield changes
15:26	@riel	or with the page table changes introduced in 2.6.12-rc1
15:28	eigood	I maintain separate debian patches against upstream(in debian/patches), so removing ones applied upstream is simple(in theory)
15:28	eigood	my patch system also supports 'dependencies', which is used for ordering
15:29	eigood	of course, I hardly ever release stuff, ...
15:31	---	---> anthill333 [~larsr@palwebproxy2.core.hp.com] has joined #xen
15:33	---	<<-- jeroney [~jeroney@pixpat.austin.ibm.com] has quit (Quit: Leaving)
15:34	---	<<-- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit (Ping timeout: 480 seconds)
15:38	---	---> greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
15:47	---	---> GN [~tjf@pat.foulston.com] has joined #xen
15:47	---	<--- GN [~tjf@pat.foulston.com] has left #xen (Leaving)
15:52	---	<<-- Sir_Ahzz [~ahzz@c-24-0-215-3.client.comcast.net] has quit (Ping timeout: 480 seconds)
15:52	---	---> Sir_Ahzz [~ahzz@c-24-0-215-3.client.comcast.net] has joined #xen
15:52	---	Channel: mode/#xen [+o Sir_Ahzz] by ChanServ
16:00	---	Netsplit oxygen.oftc.net <-> jupiter.oftc.net quits: hollis, Beirdo, muligone, VS_ChanLog, @Sir_Ahzz
16:00	---	Netsplit oxygen.oftc.net <-> jupiter.oftc.net quits: DEac-, rharper, LaidBack_01, mdday, demon, mael, Shaun, muli, surriel, schweeb, (+6 more, use /NETSPLIT to show all of them)
16:01	---	Netsplit over, joins: Beirdo, schweeb, VS_ChanLog, Arnald, eigood, surriel, hbaum, rharper, DEac-, mdday (+8 more)
16:02	---	<<-- DEac- [~deac@xdsl-213-196-206-77.netcologne.de] has quit (Quit: Leaving)
16:02	---	Netsplit over, joins: @Sir_Ahzz, hollis, muligone
16:08	---	---> DEac- [~deac@xdsl-81-173-139-25.netcologne.de] has joined #xen
16:19	Mark	Sir_Ahzz: you still about?
16:19	@Sir_Ahzz	yeah
16:19	@Sir_Ahzz	just came back inside.
16:19	@Sir_Ahzz	finished repairing the chainsaw.
16:19	Mark	That's not something you can say every day!
16:20	Mark	(well maybe you can - but I can't :-)
16:21	@Sir_Ahzz	heh
16:21	@Sir_Ahzz	the stump get's it later.
16:21	Mark	sooo, nickserv... what exactly do I have to do? this IRC business is somewhat new fangled and unfamiliar ;-)
16:21	@Sir_Ahzz	previous homeowners left a 5' tall stump right next to the front door. complete with moldy and peeling bark. 8-P
16:21	@Sir_Ahzz	do /msg nickserv help
16:21	@Sir_Ahzz	it'll reply with instructions. :)
16:22	Mark	oooh!
16:23	---	<<-- greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has quit (Ping timeout: 480 seconds)
16:24	---	<--- Mark [~MarkWilli@hebble.cl.cam.ac.uk] has left #xen (Kopete 0.9.2 : http://kopete.kde.org)
16:24	@riel	Patch #701 (linux-2.6.9-xen-compile.patch):
16:24	@riel	+ patch -p1 -s
16:24	@riel	2 out of 5 hunks FAILED -- saving rejects to file include/asm-xen/asm-i386/pgtable.h.rej
16:24	@riel	1 out of 1 hunk FAILED -- saving rejects to file include/asm-xen/asm-i386/pgtable-2level.h.rej
16:24	@riel	1 out of 1 hunk FAILED -- saving rejects to file arch/xen/i386/kernel/Makefile.rej
16:24	@riel	ok, close enough ;)
16:25	@Sir_Ahzz	fun. :)
16:25	---	---> Mark [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
16:25	---	<--- Mark [~MarkWilli@hebble.cl.cam.ac.uk] has left #xen (Kopete 0.9.2 : http://kopete.kde.org)
16:25	---	Channel: mode/#xen [+o surriel] by riel
16:25	---	---> MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
16:25	@Sir_Ahzz	mark, problems?
16:26	MarkW	sorted now
16:27	@Sir_Ahzz	ah
16:27	MarkW	Should be registered with nickserv as MarkW
16:27	@Sir_Ahzz	so is it mark or markw that you registered?
16:27	@Sir_Ahzz	ok
16:27	MarkW	there was another Mark :-(
16:27	MarkW	now why would someone be named after me...?
16:27	@Sir_Ahzz	you'r added.
16:27	@Sir_Ahzz	should get auto-oped upon joining if you have been verified by nickserv
16:28	---	Channel: mode/#xen [+o MarkW] by Sir_Ahzz
16:28		* MarkW feels his new superpowers appear
16:28	@riel	easily testabe with /cycle or /kick ;)
16:29	@MarkW	:-)
16:29	---	!!!! riel was kicked from #xen by riel (test)
16:29	---	---> riel [~riel@riel.netop.oftc.net] has joined #xen
16:29	riel	mmmm nope
16:29	@Sir_Ahzz	you verified with nickserv?
16:29	riel	yes
16:30	@Sir_Ahzz	hunh.
16:31	@Sir_Ahzz	there.
16:31	@Sir_Ahzz	fixed in the list.
16:31	@Sir_Ahzz	it lost your entry for some reason.
16:31	@Sir_Ahzz	shrug
16:31	---	<--- riel [~riel@riel.netop.oftc.net] has left #xen ()
16:31	---	---> riel [~riel@riel.netop.oftc.net] has joined #xen
16:31	---	Channel: mode/#xen [+o riel] by ChanServ
16:31	@riel	ty
16:31	@Sir_Ahzz	ahh well, back to cutting this stump outa the ground. 8-P
16:32	---	!!!! riel was kicked from #xen by riel (foo)
16:32	---	---> riel [~riel@riel.netop.oftc.net] has joined #xen
16:32	---	Channel: mode/#xen [+o riel] by ChanServ
16:32	@Sir_Ahzz	I think level 10 access grants chanserv admin rights, eg adding/removing users from the list.
16:32	@Sir_Ahzz	i'll figure it out later. :)
16:32		* Sir_Ahzz is gone. work to do.
16:32	---	Channel: mode/#xen [-o riel] by ChanServ
16:32	---	Channel: mode/#xen [+o riel] by ChanServ
16:32	@riel	cool, that works too
16:49	knewt	Sir_Ahzz: "level #xen list" should tell you what levels are needed for different rights
16:50	knewt	ah, no. levels, not level, on this network
16:59	---	---> greenrd [~greenrd@66-188-75-198.cpe.ga.charter.com] has joined #xen
17:02	@Sir_Ahzz	bah! damn chainsaw vaporlocked on me.
17:02	@Sir_Ahzz	the thing is 12 years old at least.
17:02	@Sir_Ahzz	lots of crud in the carb I bet.
17:24	---	<--- mdday [~mdday@bi01p1.nc.us.ibm.com] has left #xen (/dev/stomach)
17:31	---	<<-- Method [~Method@stanford.columbia.tresys.com] has quit (Ping timeout: 480 seconds)
17:31	knewt	MarkW: i was looking through the current xend, and it opens /proc/xen/privcmd several times. there's no problem with actually only opening it once, right? it's just how the code has been structured?
17:33	@MarkW	right
17:33	hollis	I think aliguori said it wasn't really being opened several times; it just looks like it
17:33	@MarkW	the only reason you open it is you can do ioctl()s on it. as long as you have a file descriptor to it, it doesn't matter where you got it from
17:34	@MarkW	hollis: seems quite possible
17:34	knewt	and if a process running as root opens /proc/xen/privcmd and then gives up root privs then everything will still work?
17:34	hollis	something about "lazy opening"... but maybe that was vm-tools and not xend? I didn't pay attention
17:34	knewt	hollis: i think you're thinking about vm-tools
17:34	hollis	ok
17:34	@MarkW	hollis: that was libxen, not the current tools
17:35	@MarkW	knewt: you need to be able to mlock stuff in order to use the privcmd interface
17:35	@MarkW	no good passing stuff to Xen that's been paged out...
17:35	---	User: *** riel is now known as unriel
17:35	knewt	hollis: xend creates multiple instances of the python xc object with xen.lowlevel.xc.new(), each one calling xc_interface_open
17:36	@MarkW	knewt: in that case it really is opening it multiple times, i agree
17:36	knewt	MarkW: ah, so need to keep hold of root privs then?
17:36	---	<<-- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has quit (Remote host closed the connection)
17:36	---	---> MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
17:36	MarkW	oops, my irc client died
17:41	---	---> Method [Method@pcp0010742058pcs.howard01.md.comcast.net] has joined #xen
17:41	---	<<-- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit (Read error: Connection reset by peer)
17:42	---	---> Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
17:43	knewt	MarkW: ok, so i need mlock. is that it? if so then i can just drop all capabilities other than CAP_IPC_LOCK once i've opened /proc/xen/privcmd
17:43	MarkW	knewt: i think that should work, yes
17:44	knewt	since i don't need to execve at any point, so i won't fall foul of the issues with capabilities
18:07	---	User: *** surriel is now known as riel
18:09	---	<<-- hollis [~hollis@pixpat.austin.ibm.com] has quit (Quit: leaving)
18:10	aliguori	knewt: an alternative approach would be using mlockall(MCL_FUTURE) and then dropping privileges
18:10	aliguori	that should work
18:11	aliguori	knewt: i'm not sure you're all that much better off though dropping privileges if you can write to privcmd. You can find creative ways to map the full address space of dom0 and do whatever evil things you'd like to do
18:12	aliguori	having access to privcmd is far more dangerous than being root.
18:14	knewt	yeah, i guess
18:20	eigood	nothing is more dangerous than being root
18:23	MarkW	eigood: in dom0, i guess that's true
18:24	MarkW	which implies that privcmd access === dom0's root === everyone else's root, after a fashion
18:24	eigood	since root can open privcmd, being not root but having access to privcmd doesn't make you more dangerous that root
18:25	eigood	if domU can open privcmd and access dom0's mem, then xen is broken.
18:25	eigood	now, if the request goes to dom0, which can arbitrate it, then that's fine
18:25	MarkW	eigood: it can't unless you make the domU privileged
18:25	eigood	but, in all honest, domU should not be able to open control c hannels with other domains; data channels, yes, if you already have a control channel open
18:26	MarkW	not sure what you mean there...
18:27	eigood	dom0 sets up control channels between different domU, then those domU can communicate with each other
18:27	eigood	think advanced cluster applications
18:27	cw	eigood: if you root a domU and send spasticaed messages to another domain via Xen it shouldn't break things. if it does then it's a bug and should be reported and fixed.
18:27	eigood	I'm speaking hypothetical
18:28	MarkW	eigood: yeah ok. domUs can't get at each other's control channels directly, so it's ok.
18:29	MarkW	opening inter-domU data channels will need the grant tables stuff, which is still being baked right now
18:39	cw	probably there are ways if you try hard and long enough to break things from domU --- but as these get discovered they will be fixed over time
18:43	MarkW	cw: there are at least 1 or 2 vulnerabilities in Xend, if you count DoS attacks from a domU
18:47	cw	sure, and im sure given time people will fix these and/or post patches
18:47	cw	speaking of which is there a bug-db on xensource.com ... i didnt see one but i wasn't looking either
18:48	MarkW	yes. the new control tools will hopefully eliminate these problems
18:48	MarkW	i don't think the bug tracker is online yet, i'm not sure what's happening with that
18:49		* cw hopes it's not bugzilla
18:50	eigood	the latest bugzilla has some nice features
18:50	eigood	time tracking, better permissions/separator
19:04	---	<<-- rharper [~rharper@pixpat.austin.ibm.com] has quit (Quit: Leaving)
19:06	---	<<-- rocket [~rocket@c-66-41-176-53.hsd1.mn.comcast.net] has quit (Read error: Connection reset by peer)
19:07	eigood	internal/external user support
19:12	cw	it's just very complicated and overdesigned for some uses, whatever works though
19:15	eigood	we haven't used the new version yet tho
19:17	@riel	I'm not aware of any nice bug tracking software
19:17	aliguori	yeah, neither am i. it's harder to get right than you'd think
19:19	aliguori	it's hard to denoise a bug tracking system in open source projects too.. we get tons of duplicates in samba because users don't search for a bug before they report it
19:20	---	<<-- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit (Quit: Client exiting)
19:23	@riel	lets just fix the bugs before users run into them ;)
19:23	@riel	or let the distributions and xensource support people keep track of bugs
19:27	aliguori	:-) that's fine by me
19:29	aliguori	riel: are you guys taking xen-related bugs yet in fedora?
19:30	aliguori	ah, quick search looks like you are :-)
19:30	eigood	debian has been for a long time
19:32	aliguori	debian's had good xen support.. i can't figure out what gentoo's doing about xen though. there was a bug with an ebuild but that seems to have disappeared
19:48	---	<--- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has left #xen ()
19:48	---	---> cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has joined #xen
20:00	---	---> rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:16	@riel	hey rusty
20:18	---	<<-- rusty [~rusty@bh02i525f01.au.ibm.com] has quit (Ping timeout: 480 seconds)
20:20	@riel	mmm, I'll try that again when he rejoins
20:20	@riel	;)
20:24	---	<--- cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has left #xen ()
20:24	---	---> cw [cw@adsl-63-202-174-57.dsl.snfc21.pacbell.net] has joined #xen
20:25	cw	riel: do you use a registered nick with oftc? and if so do you have working access lists?
20:25	@riel	yes
20:25	cw	hrm... buggered if i know what im doing wrong then, i have a fairly generous access list and it never recognises me
20:26	---	Channel: mode/#xen [-o unriel] by ChanServ
20:26	---	Channel: mode/#xen [-o riel] by riel
20:29	---	<--- Beirdo [~gjhurlbu@beirdo.usercloak.oftc.net] has left #xen (Leaving)
20:44	LaidBack_01	aliguori, gentoo doesn't have a xen maintainer currently - so the project fell off the map for gentoo.
20:46		* riel upgrades rawhide's kernel to today's Xen code
20:46	riel	(I'll commit it after I've tested it)
20:47	cw	riel: you run aim7 nightly on smp guests?
20:47	riel	cw: no
20:47	riel	I need to automate my tests
20:48	riel	but it's more important to have the packages out there, so other people can run automated tests ;)
20:50	Method	riel: a few weeks ago the fedora kernel apparently had a newer version of xen than the xen cvs did, the xen cvs was identifying itself as version 2 but the fedora one was 3, what was the deal with that?
20:51	riel	I track xen-unstable
20:51	---	---> rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:51	riel	hi rusty
20:51	Method	i'm pretty sure thats what cvs i had but maybe not
20:51		* riel waits for the ping timeout ;)
20:52	riel	Method: I often package the kernel part fresh from the bitkeeper tree
20:52	MarkW	Method: there's three bitkeeper trees, -stable, -testing, -unstable
20:52	Method	s/cvs/bk/
20:52	Method	yea, i had unstable
20:52	cw	riel: have you seen the performance regression/problems others are reporting on dumU with vbd?
20:52	Method	i was fairly confused
20:52	riel	cw: I haven't tested
20:52	riel	cw: but Jens Axboe's patch should help
20:52	MarkW	-stable and -testing are the 2.0 series, -unstable is where the 3.0 series is being developed
20:52	riel	(and is part of the code changes I want to put into rawhide tonight)
20:53	Method	$ bk parent
20:53	Method	Parent repository is bk://xen.bkbits.net/xeno-unstable.bk
20:53	Method	yea.. maybe it was wierd timing
20:54	riel	if you've seen a patch on xen-changelog, it's available on bkbits.net
20:55	riel	(that's where I pull from for the changelog mails)
20:56	MarkW	Method: something weird must have happened :-)
20:57	cw	actually, sometimes i notice the parent repo changes to something inconsistent
20:58	cw	ive had to rm and reclone, pull just barfs or finds conflicts... think that was for xen-2.0-testing.bk but not 100% sure
20:58	MarkW	cw: could be a bitkeeper bug i guess
20:59	MarkW	i have (very occasionally) wedged my repo into states that confuse BK
21:14	cw	MarkW: looks more like the parent was recreated / resynced from somewhere else
21:14	cw	MarkW: 'bk changes -L' would show i had things the parent didn't --- yet i never made those changes
21:14	MarkW	ooh, that's a bit weird
21:14	riel	indeed, Ian did a 'bk undo' once
21:14	riel	by accident
21:14	cw	MarkW: maybe the parent has undo's done at times? that would explain it
21:14	MarkW	the parent being at bkbits?
21:14	cw	yeah, that's would bo it
21:14	cw	do it
21:15	cw	bk cset -x, not undo :)
21:15	cw	MarkW: yeah, bk://xen.bkbits.net/xeno-unstable.bk or similar... i forget now
21:15	MarkW	ok
21:15		* MarkW has one more bug to squash before sleep
21:16	riel	cw: exactly
21:18	MarkW	is there actually anyone else here on London time?
21:18	MarkW	(just curious)
21:20	riel	not this week ;)
21:20	MarkW	right :-) where are you based usually / on average / nominally (delete as appropriate)?
21:24	---	---> Gollum [~gollum@pcp01411681pcs.phnixv01.pa.comcast.net] has joined #xen
21:41	niv	MarkW: whom are you asking? riel? (EST?). Some of us are in Oregon (PST) where it is now 6:41PM
21:42	MarkW	anyone and everyone :-) just curious.... on british summer time (where I am) it's 3.42am
21:43	niv	MarkW: they're working you much too hard up there, laddie ;)
21:43	MarkW	of course I actually have my own personal timezone, so it's not as bad as it sounds ;-)
21:43	---	<<-- Gollum [~gollum@pcp01411681pcs.phnixv01.pa.comcast.net] has quit (Read error: Operation timed out)
21:44	MarkW	niv: i have one more bug that i'm determined to squash tonight... it's really bugging me!
21:44	niv	always handy, yer own time and space :)
21:44	niv	me too
21:44	niv	what are you working on?
21:44	MarkW	I'm hacking on XenFS most of the time now
21:45	niv	ah
21:45	niv	how's that coming along?
21:45	MarkW	(for those who haven't heard of it XenFS is a bit like NFS but exploiting all all the servers / clients being able to share memory directly)
21:46	MarkW	it's coming along OK now I'm concentrating on it
21:46	aliguori	MarkW: is a copy available yet? :-) I'm very anxious to see it
21:46	MarkW	aliguori: it's not ready for other people to look at the code yet - might make them queasy
21:46	aliguori	heh, i hope it's not too much like NFS :-)
21:46	MarkW	aliguori: so do I :-D
21:47	MarkW	i'll make some code available as soon as it's reasonably sane.
21:47	MarkW	the really interesting stuff is the optimisations i can do later on, however...
21:47	aliguori	is it a point-to-point file system or can it be shared between 2 or more domains?
21:48	niv	the world is very short of a good network file system. Xen lends itself to a lot more exploitation and gain here - should be really interesting
21:48	MarkW	aliguori: the sharing is where things get rather interesting
21:48	aliguori	niv: yup, it's becomes particularly interesting when you try to match the semantics of multiple platforms
21:48	aliguori	MarkW: that's what I figured :-)
21:48	MarkW	things I may look at:
21:49	MarkW	providing CoW functionality in the server to minimise disk usage
21:50	MarkW	sharing common memory pages between domains to minimise IO / save memory
21:50	MarkW	write sharing (i'd like to do this by direct memory sharing but i don't know if that's sane yet)
21:51	MarkW	but first I have to make the basics sane :-D
21:51	aliguori	CoW at what level? on a per-block basis or per-inode?
21:51	MarkW	per inode
21:51	aliguori	we've been looking at unionfs.. even though it's file-level CoW it's quite useful in a virtualized environment
21:52	MarkW	we had an NFS server that did CoW at filesystem level but that didn't perform well...
21:52	MarkW	aliguori: yes that would do the job nicely - whose implementation are you using?
21:52	aliguori	the FiST one.
21:53	aliguori	http://www.fsl.cs.sunysb.edu/project-unionfs.html
21:53	MarkW	ah, ok
21:53	aliguori	it's quite neat in with xen because you can just share a common read-only device and give each domain a small rw device for CoW
21:53	niv	aliguori: thanks for the url
21:54	niv	what are you using it for?
21:54	aliguori	the only real performance problem i can think of is reading a directory (because unionfs has to merge two directories--if there's a ton of files in both directories it could be expensive)
21:55	aliguori	niv: we've been looking at it for our ols proposal
21:55	niv	are you going to present that at ols?
21:55	aliguori	niv: i've gotta give credit to rharper, i had given up on it but he showed me that i was just being a stupid user :-)
21:56	aliguori	niv: i don't know. we're looking at a lot of things right now
21:56	aliguori	the problem with unionfs is that it's not really practical. the code base won't likely make it into the kernel
21:56	aliguori	the FiST stuff is too clunky
21:57	niv	aliguori: what else is there on the horizon in this space, though, that you know of?
21:57	aliguori	niv: well, i've got a personal bias to content-addressable solutions like Venti
21:57	aliguori	:-)
21:58	aliguori	there was an old linux CoW filesystem called IFS that eventually was removed from the kernel for lack of maintainership
21:58	aliguori	sun has one (tranparent file system or something like that i believe)
21:59	niv	nothing that seems to have really gotten mindshare
21:59	aliguori	translucent, sorry
21:59	aliguori	not that i know of. i think TFS is perhaps the most well known
22:00	aliguori	unless you of course count the copy-on-write features in CIFS :-)
22:01	riel	MarkW: I'm in Nashua, NH, US - it's 22:02 here
22:01	riel	(and the kernel RPM compile seems to have finished - testing time in a bit)
22:02	aliguori	man, i guess i'm the only one in CST.. there normally are a bunch of texas folks here though :-)
22:02	niv	is SMP compile broken? there were rumors to that effect here which I wasn't paying close attention to
22:03	---	<<-- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit (Read error: Connection reset by peer)
22:03	niv	aliguori: ah, CST, where it's neither too late nor too early :)
22:04	riel	Subject: [Xen-changelog] Fix queue unplugging in blkback driver.
22:04	riel	oh great
22:04	riel	I thought that one was committed way earlier today
22:04	aliguori	time to rebuild kernel rpms :-)
22:04	riel	Subject: [Xen-changelog] Patch from Jens Axboe to synchronously flush block
22:04	riel	oh n/m, it was
22:08	riel	two patches in the same area
22:10	riel	if this stuff breaks, I'll try again tomorrow morning ;)
22:10	riel	with newer code
22:13	niv	riel: i think you have everything so far, this might work
22:13	riel	I only have the second one - not the first one
22:15	riel	ok, looks like I need a newer xen, too
22:16	riel	NET: Registered protocol family 17
22:16	riel	inst3: 0000 [#1]
22:16	riel	SMP end_stop disable_local_APIC
22:16	riel	(XEN)
22:16	riel	Domain 0 shutdown: rebooting machine.
22:16	riel	this is annoying too
22:17	riel	ok, I'll look at this tomorrow
22:17	riel	enough for today
22:18		* niv is going to get some dinner..
22:18	---	<<-- niv [~niv@bi01p1.co.us.ibm.com] has quit (Quit: ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217])
22:18		* MarkW has conquered another xenfs bug
22:19	MarkW	time for bed :-)
22:19	---	---> Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
22:19	---	<<-- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has quit (Quit: Kopete 0.9.2 : http://kopete.kde.org)
22:37	riel	ok cool, the kernel boots with a new xen
22:45		* riel pushes both xen and the new kernel into the build system
22:47	schweeb	riel: which version of python are you using with the userspace stuff?
22:47	riel	oh crud !
22:47	schweeb	we've had a couple problems with 2.4 on ubuntu
22:47	riel	Call Trace:
22:47	riel	[<c025638a>] blk_run_queue+0x1a/0x50
22:47	riel	[<c0265744>] blkio_schedule+0x134/0x160
22:47	riel	[<c011a730>] default_wake_function+0x0/0x20
22:47	riel	[<c0265610>] blkio_schedule+0x0/0x160
22:47	riel	[<c01080cd>] kernel_thread_helper+0x5/0x18
22:47	riel	shit
22:47	schweeb	heh
22:47	riel	so I do need both patches
22:54	rusty	Hi Rik!
22:56	---	---> jeroney [~jeroney@rrcs-24-173-250-83.sw.biz.rr.com] has joined #xen
22:59	riel	rusty: time to put the latest (and greatest?) xen code in rawhide ;)
22:59		* riel just pulled and fixed up linux-2.6.11-xen.patch
23:00	rusty	riel: cool.
23:02	riel	(for the second time today)
23:02	riel	the code I had yesterday was stable
23:02	riel	it survived an overnight aim7 run, on a xenU guest with 3 cpus
23:22	jeroney	riel: good to see xen back in rawhide :-)
23:23	riel	yeah
23:59	---	<--- VS_ChanLog [~stats@ns.theshore.net] has left #xen (Rotating Logs)
23:59	---	---> VS_ChanLog [~stats@ns.theshore.net] has joined #xen
---	Log	closed Fri Apr 01 00:00:39 2005