TheGrebs.com:IRC Logs:#xen:2005:04:13

---	Log	opened Wed Apr 13 00:00:47 2005
00:13	itamarjp	'[root@router conacci]# e2fsck -f root_fs.ext3 -y
00:13	itamarjp	e2fsck 1.36 (05-Feb-2005)
00:13	itamarjp	Pass 1: Checking inodes, blocks, and sizes
00:13	itamarjp	Pass 2: Checking directory structure
00:13	itamarjp	Pass 3: Checking directory connectivity
00:13	itamarjp	Pass 4: Checking reference counts
00:13	itamarjp	Pass 5: Checking group summary information
00:13	itamarjp	root_fs.ext3: 53583/128000 files (0.2% non-contiguous), 140324/256000 blocks
00:13	itamarjp	[root@router conacci]# dd if=/dev/zero of=root_fs.ext3 bs=1 count=1 seek=40G conv=notrunc
00:13	itamarjp	1+0 records in
00:13	itamarjp	1+0 records out
00:13	itamarjp	[root@router conacci]# resize2fs -p root_fs.ext3
00:13	itamarjp	resize2fs 1.36 (05-Feb-2005)
00:13	itamarjp	resize2fs: File too large while trying to determine filesystem size
00:13	itamarjp	[root@router conacci]#
00:13	itamarjp	[root@router conacci]#
00:36	---	---> knewt [~jmb@zeus.pimb.org] has joined #xen
00:39	---	---> N [~ca4bc809@webuser.thegrebs.com] has joined #xen
00:48	---	<<-- itamarjp [lualele@terra-200-225-254-003-dynamic.idial.com.br] has quit (Quit: )
02:36	---	<<-- rusty [~rusty@bh02i525f01.au.ibm.com] has quit (Quit: Client exiting)
02:41	---	<<-- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has quit (Remote host closed the connection)
03:13	mael	hi
03:16	muli_	hello mael
03:17	---	<<-- DEac- [~deac@xdsl-213-196-196-194.netcologne.de] has quit (Ping timeout: 480 seconds)
03:28	murb	anyone seem stuff like panic: HYPERVISOR_mmu_update failed
03:29	---	---> DEac- [~deac@xdsl-84-44-151-129.netcologne.de] has joined #xen
03:29	murb	this is with NetBSD/xenU whilst somthing was trying to read /dev/mem
03:36	---	---> hebutterworth [~harry@blueice1n1.uk.ibm.com] has joined #xen
03:40	---	---> athomas [~athomas@ppp-0-48.lond-b-3.access.uk.tiscali.com] has joined #xen
04:36	---	<<-- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has quit (Quit: Leaving)
05:04	---	<<-- DEac- [~deac@xdsl-84-44-151-129.netcologne.de] has quit (Ping timeout: 480 seconds)
05:04	---	---> soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
05:18	---	---> DEac- [~deac@xdsl-213-196-198-220.netcologne.de] has joined #xen
05:24	---	---> karloz [~charles@ca-bordeaux-2-23.w80-8.abo.wanadoo.fr] has joined #xen
05:35	---	<--- karloz [~charles@ca-bordeaux-2-23.w80-8.abo.wanadoo.fr] has left #xen ()
05:37		* surriel fixes up xenolinux for Roland's latest execshield-vdso improvements
06:12	---	---> MarkWilliamson [~MarkW@maw48.kings.cam.ac.uk] has joined #xen
06:18	mael	MarkWilliamson: wow
06:18	mael	I'm impressed
06:18	MarkWilliamso	\| mael: oh?
06:18	mael	I thought you would come around 8pm after being up so late yesterday :)
06:18	MarkWilliamso	\| I thought you might say that :-)
06:19	mael	thanks for your answear on the L4 vs. xen issue
06:19	MarkWilliamso	\| today is unusually early... i don't like mornings :-)
06:20	mael	hehe I don't either
06:21	mael	I read the safe hardware access paper yesterday
06:21	mael	It is very interesting
06:21	mael	some of my questions found answears
06:21	hebutterworth	\| Mark, quick question about protocol:
06:22	MarkWilliamso	\| yup
06:22	hebutterworth	\| Are the driver status down messages notification that the driver is down
06:22	hebutterworth	\| or are they requests for xend to take the interfaces down so that the driver can exit cleanly?
06:23	MarkWilliamso	\| I think they're the former, hang on
06:27	MarkWilliamso	\| Well the driver status UP messages are notifications that the driver is here and it wants Xend to talk to it
06:27	MarkWilliamso	\| so I think the DOWN messages are the inverse
06:28	MarkWilliamso	\| i.e. the former of your statements
06:28	hebutterworth	\| So, that would imply that if the FE driver module wants to unload, it would send an interface disconnect message for all interfaces and wait for the interface status to become disconnected before finally sending a driver status down and exiting.
06:29	MarkWilliamso	\| yes, that's what i'd envision. a quick grep tells me that driver DOWN messages is never used for any of the devices, so if you implement something then that'll be the de facto standard ;-)
06:30	hebutterworth	\| OK. So what about unloading the back end module?
06:31	hebutterworth	\| The back-end could stop using all shared pages then send a driver status down.
06:31	hebutterworth	\| Or the back end could send a driver status down and wait for xend to disconnect all interfaces and destroy all devices before exiting.
06:31	MarkWilliamso	\| I think the backend should probably send close, then disconnect messages for all the interface
06:32	hebutterworth	\| The back-end doesn't ever send any messages like that.
06:32	hebutterworth	\| There aren't any.
06:33	MarkWilliamso	\| what i meant to say was "cause to be sent to the front end"
06:34	MarkWilliamso	\| of course, it depends what you want this to look like to the front ends
06:34	hebutterworth	\| So I was thinking that the back-end would cease to use all shared resources then send a back-end driver down message
06:34	MarkWilliamso	\| yeah, that sounds reasonable.
06:34	hebutterworth	\| Then xend would send an fe interface status destroyed to the front end
06:35	MarkWilliamso	\| ^ i.e. do the frontends see a backend driver domain restart, or the complete removal of the interface
06:36	hebutterworth	\| How did the sequencing work for restartable driver domains that was written up in one of the papers I read?
06:37	hebutterworth	\| Was that actually implemented?
06:37	MarkWilliamso	\| if you (the frontend) get a DISCONNECTED message when you were CONNECTED then you expect it's a backend restart
06:38	hebutterworth	\| OK
06:38	MarkWilliamso	\| you then run the state machine as normal to make a new connection
06:38	MarkWilliamso	\| the code i put into the 2.4 driver for supporting suspend / migration should cope with this (or be pretty close)
06:40	MarkWilliamso	\| but i haven't been able to test this whilst suspend / migrate is broken in the unstable tree (i.e. broken for everything) - I've had an initial look at fixing the migration code but the debugging got a bit involved
06:40	hebutterworth	\| So, I guess one question then is whether a back end driver module unload should look like a driver domain restart
06:40	hebutterworth	\| Maybe it should.
06:40	MarkWilliamso	\| Xfrd is rather complicated and its difficult to trace exactly what's breaking it right now
06:40	MarkWilliamso	\| it probably depends! ;-)
06:41	MarkWilliamso	\| probably just notifying the frontend if a new backend is loaded might work
06:43	hebutterworth	\| The only difficult thing about writing the code is trying to work out what behaviour you want.
06:44	MarkWilliamso	\| you're in uncharted territory here - we don't have a standard to work to because we don't have any unloadable modules
06:45	hebutterworth	\| OK. Well, I'll think more about it.
06:45	MarkWilliamso	\| however, I guess you could arrange for the code to be reasonably reusable in the other backends (it should look pretty similar for all of them)
06:45	MarkWilliamso	\| and then we would have a standard :-)
06:46	MarkWilliamso	\| I need to go eat, etc, now or I won't be very useful. See you later.
06:46		* MarkWilliams goes
06:46	hebutterworth	\| OK. Thanks for your help.
07:39	@surriel	there, kernel-2.6.11-1.1240 will have Xen again
07:40	@surriel	and thanks to Roland's VDSO patch, there's no need for arch/xen/i386/kernel/signal.c any more
08:38	---	---> hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
08:47	---	---> rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
08:50	---	<<-- monrad [~monrad@213083190130.sonofon.dk] has quit (Quit: Leaving)
09:03	---	User: *** unriel is now known as riel
09:08	riel	Failed update VA mapping: bf9e1f48, 03696067, 00000000
09:08	riel	------------[ cut here ]------------
09:08	riel	kernel BUG at include/asm-xen/hypervisor.h:484!
09:08	riel	awww crud
09:09	riel	dom0 works great, though
09:11	@Sir_Ahzz	heh
09:15	riel	guess I'll have something fun to track down this morning
09:19	---	<--- MarkWilliamson [~MarkW@maw48.kings.cam.ac.uk] has left #xen (Kopete 0.10 : http://kopete.kde.org)
09:19	---	---> hbaum [~hbaum@pixpat.austin.ibm.com] has joined #xen
09:47	---	<<-- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit (Ping timeout: 480 seconds)
10:04	---	---> cfreak [cfreak@84.56.98.175] has joined #xen
10:16	eigood	Sir_Ahzz: I've got debs of iscsi enterprise target
10:16	eigood	including a proper kernel module source deb
10:18	---	---> yazid_work [~chatzilla@blaubaer.iehk.RWTH-Aachen.DE] has joined #xen
10:20	yazid_work	any way to use networking software that needs layer 2 multicast capabilities (eg netatalk) within an unprivileged domain? yep, googled intensely without getting any useful answers
10:27	---	<<-- yazid_work [~chatzilla@blaubaer.iehk.RWTH-Aachen.DE] has quit (Remote host closed the connection)
10:35	---	---> rharper_ [~rharper@pixpat.austin.ibm.com] has joined #xen
10:39	---	<<-- rharper [~rharper@pixpat.austin.ibm.com] has quit (Ping timeout: 480 seconds)
10:41	eigood	use ebtables
10:41	eigood	and bridging
10:41	mael	eigood: he left :)
10:43	eigood	people don't know how to use irc
10:43	---	<<-- muli_ [~muli@nesher3.haifa.il.ibm.com] has quit (Ping timeout: 480 seconds)
10:47	---	<<-- [e]num [~enum@cpe-24-175-6-109.houston.res.rr.com] has quit (Quit: Leaving)
10:48	---	<<-- cfreak [cfreak@84.56.98.175] has quit (Read error: Connection reset by peer)
10:50	---	---> cfreak [cfreak@dsl-084-056-098-175.arcor-ip.net] has joined #xen
10:54	---	---> jimix [~jimix@p181.n-lapop01.stsn.com] has joined #xen
10:57	---	---> niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
11:01	@Sir_Ahzz	eigood, kewl. I'll give them a try later.
11:02	@Sir_Ahzz	running special debug version right now to try and trap the recurring glith that's sending ISTD into infinite loop of 100% cpu.
11:02	@Sir_Ahzz	triggered by a network event, llooks like a disconnect with some unknown special "quality" that triggers it.
11:04	---	<<-- cw [cw@adsl-68-120-153-162.dsl.snfc21.pacbell.net] has quit (Read error: Connection reset by peer)
11:06	eigood	Sir_Ahzz: haven't uploaded them
11:08	---	---> cw [cw@adsl-68-120-153-162.dsl.snfc21.pacbell.net] has joined #xen
11:32	---	---> hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
11:44	---	<<-- jimix [~jimix@p181.n-lapop01.stsn.com] has quit (Remote host closed the connection)
11:45	---	---> jimix [~jimix@p181.n-lapop01.stsn.com] has joined #xen
11:54	---	---> monrad [~monrad@x1-6-00-09-6b-3f-ee-63.k138.webspeed.dk] has joined #xen
11:59	---	<<-- N [~ca4bc809@webuser.thegrebs.com] has quit (Quit: http://thegrebs.com/oftc/ (EOF))
12:07	---	<<-- niv [~nivedita@bi01p1.co.us.ibm.com] has quit (Ping timeout: 480 seconds)
12:09	---	<<-- athomas [~athomas@ppp-0-48.lond-b-3.access.uk.tiscali.com] has quit (Quit: Leaving)
12:19	---	---> niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
12:28	---	---> cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has joined #xen
12:36	---	<<-- jimix [~jimix@p181.n-lapop01.stsn.com] has quit (Quit: Download Gaim: http://gaim.sourceforge.net/)
12:37	---	---> Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has joined #xen
12:51	---	---> cw_ [cw@adsl-63-202-174-40.dsl.snfc21.pacbell.net] has joined #xen
12:56	---	---> matta-lt [~matta@69.93.28.254] has joined #xen
12:57	---	<<-- soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit (Quit: Leaving)
12:58	---	<<-- cw [cw@adsl-68-120-153-162.dsl.snfc21.pacbell.net] has quit (Ping timeout: 480 seconds)
13:27	---	---> jimix [~jimix@p181.n-lapop01.stsn.com] has joined #xen
13:34	---	<<-- jimix [~jimix@p181.n-lapop01.stsn.com] has quit (Quit: Download Gaim: http://gaim.sourceforge.net/)
13:35	---	---> jimix [~jimix@p181.n-lapop01.stsn.com] has joined #xen
13:42	---	---> jeroney [~jeroney@pixpat.austin.ibm.com] has joined #xen
13:51	---	---> _MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
13:53	---	<<-- DEac- [~deac@xdsl-213-196-198-220.netcologne.de] has quit (Quit: Verlassend)
13:54	---	---> DEac- [~deac@xdsl-213-196-198-220.netcologne.de] has joined #xen
13:54	---	<--- _MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has left #xen ()
13:55	---	---> _MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
13:59	---	<<-- jimix [~jimix@p181.n-lapop01.stsn.com] has quit (Quit: Download Gaim: http://gaim.sourceforge.net/)
14:01	---	---> jimix [~jimix@p181.n-lapop01.stsn.com] has joined #xen
14:01	---	<<-- niv [~nivedita@bi01p1.co.us.ibm.com] has quit (Quit: Quitting)
14:03	---	<<-- jimix [~jimix@p181.n-lapop01.stsn.com] has quit (Quit: )
14:09	---	<<-- cfreak [cfreak@dsl-084-056-098-175.arcor-ip.net] has quit (Quit: .)
14:21	---	---> niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
15:18	---	---> tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
15:28	---	---> GvG [GvG@geldorp.xs4all.nl] has joined #xen
16:08	---	---> jimix [~jimix@12.129.240.181] has joined #xen
16:31	---	---> Lampy [~jon@dynamic-62-56-56-69.park-s46b.dslaccess.co.uk] has joined #xen
16:31	---	User: *** riel is now known as unriel
16:35	---	<<-- monrad [~monrad@x1-6-00-09-6b-3f-ee-63.k138.webspeed.dk] has quit (Quit: Leaving)
16:39	---	<--- Lampy [~jon@dynamic-62-56-56-69.park-s46b.dslaccess.co.uk] has left #xen ()
16:41	---	<<-- jimix [~jimix@12.129.240.181] has quit (Quit: Download Gaim: http://gaim.sourceforge.net/)
16:41	---	---> jimix [~jimix@p182.n-lapop01.stsn.com] has joined #xen
16:52	---	<<-- matta-lt [~matta@69.93.28.254] has quit (Quit: Hey! Where'd my controlling terminal go?)
17:11	---	---> matta-lt [~matta@69.93.28.254] has joined #xen
17:26	---	<<-- GvG [GvG@geldorp.xs4all.nl] has quit (Quit: Goodnight)
17:30	---	<<-- jimix [~jimix@p182.n-lapop01.stsn.com] has quit (Ping timeout: 480 seconds)
18:00	---	<<-- DEac- [~deac@xdsl-213-196-198-220.netcologne.de] has quit (Ping timeout: 480 seconds)
18:07	---	<<-- hollis [~hollis@pixpat.austin.ibm.com] has quit (Quit: leaving)
18:07	---	<<-- hbaum [~hbaum@pixpat.austin.ibm.com] has quit (Quit: Client exiting)
18:11	---	---> DEac- [~deac@xdsl-84-44-149-187.netcologne.de] has joined #xen
18:11	---	---> jimix [~jimix@p182.n-lapop01.stsn.com] has joined #xen
18:14	---	<<-- jimix [~jimix@p182.n-lapop01.stsn.com] has quit (Quit: )
18:24	---	---> monrad [~monrad@213083190130.sonofon.dk] has joined #xen
18:42	---	User: *** _MarkW is now known as MarkW
18:44	---	<--- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has left #xen (Kopete 0.9.2 : http://kopete.kde.org)
18:44	---	---> MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
18:44	---	Channel: mode/#xen [+o MarkW] by ChanServ
19:20	---	---> rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
19:21	rusty	aliguori: ping?
19:28	@MarkW	it's a bit empty here tonight
19:28	@MarkW	maybe there's a party i don't know about!
19:28	@MarkW	* tumbleweeds roll across the ghost channel of #xen *
19:30	niv	rusty: anthony's probably gone for food -they had a mtg upto 6:30PM Austin local time
19:34	niv	MarkW: well, this is a virtual reality of sorts, isn't it, with electronic bits flying across cyberspace. there's not much substance to this transitory information age to speak of :)
19:35	niv	so, just ghostlier than normal :)
19:35	@MarkW	true, true
19:35	@MarkW	OTOH, at least it gives me less excuse not to work!
19:36	niv	and not that we didn't appreciate your elegant prose ;)
19:39	@MarkW	I don't suppose anybody has tried using mem=... to give a domain a larger memory map than the (inital) allocation of memory?
19:39	@MarkW	If I do this for dom0, it hangs during boot, which is a pain.
19:39	niv	i'm about to reboot and create a new domain - would you like me to try?
19:39	@MarkW	That'd be good, thanks.
19:40	niv	running unstable from yesterday..
19:40	@MarkW	mem=size[kMG] should work
19:40	@MarkW	you're more up to date - it'd be nice if its been fixed!
19:40	rusty	niv: Oh, OK. I've been trying to catch hi,
19:40	niv	allrighty, give me a few
19:54	niv	MarkW: still broken :(
19:54	@MarkW	niv: interesting. did you try it in a domU or in dom0?
19:54	niv	domU
19:54	niv	er, typo, dom0
19:55	niv	rebooting and trying in domU
19:55	niv	solid hang
19:55	@MarkW	OK. Thanks for checking it out.
19:55	@MarkW	It's weird.
20:04	aliguori	rusty: hey rusty
20:05	---	<<-- jeroney [~jeroney@pixpat.austin.ibm.com] has quit (Remote host closed the connection)
20:05	aliguori	rusty: just got back from a dinner with bruce, heading back home.. i'll be back in a few
20:05	---	<<-- aliguori [~anthony@pixpat.austin.ibm.com] has quit (Quit: Leaving)
20:06	---	---> hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
20:19	---	---> aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
20:20	aliguori	rusty: am back
20:25	---	<<-- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has quit (Ping timeout: 480 seconds)
20:32	@MarkW	woohoo! XenFS just did a page flipping / sharing transfer, rather than a straight copy.
20:32	aliguori	MarkW: exciting! when do we get to see the source? :-)
20:32	aliguori	i've told some FS folks here about it and they're very intested to see what you come up with
20:33	@MarkW	it'll be at least a few weeks before i have something coherent enough to be worth looking at. but it's a very good sign that the transfers work already, anyhow.
20:34	@MarkW	(if not quite reliably ;-) )
20:34	aliguori	:)
20:42	rusty	aliguori: I have all today free to work on the registry stuff, so should get it out soon.
20:42		* surriel plays with blogging software
20:50	aliguori	rusty: awesome, care to give a brief overview of your plans with the registry?
20:51	@MarkW	rusty: i'd also be interested to hear what you've come up with.
20:52	rusty	aliguori: well, it can speak to tools locally (sockets) and also using some (handwave!) mechanism to the domains.
20:52	rusty	aliguori: fairly simple interface, twists include permissions (for domains) and transactions.
20:52	niv	rusty: af_unix or af_inet?
20:53	rusty	niv: af_unix for the moment. af_inet means I have to worry about endianness, which I can do later.
20:53	niv	rusty: agreed
20:54	rusty	niv: also, the current model uses two sockets: a 0660 one which gives read-only registry access, and a 0600 which gives full read-write access.
20:54	rusty	niv: for TCP sockets, we need some auth system.
20:54	niv	rusty: that's nice.
20:55	---	User: *** cw_ is now known as cw
20:55	---	<--- cw [cw@adsl-63-202-174-40.dsl.snfc21.pacbell.net] has left #xen ()
20:55	---	---> cw [cw@adsl-63-202-174-40.dsl.snfc21.pacbell.net] has joined #xen
20:55	---	Channel: mode/#xen [+o cw] by ChanServ
20:55	rusty	niv: testsuite doesn't exist yet though... trying to get enough so people can complain about the interface fiurst.
20:56	---	Channel: mode/#xen [+o rusty] by cw
20:56	---	User: *** cw is now known as anticw
20:57	niv	rusty: i expect there will be a fair amount of discussion on the interface, yes, might want to hold off other details till it stabilizes
20:57	@rusty	niv: Well, I based it on the two documents out there about the interface. To make more progress we really need something concrete.
21:00	---	<<-- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit (Quit: Everybody wants to go to heaven, but nobody wants to die.)
21:00	@rusty	niv: also, simple hacking is fun.
21:05	aliguori	rusty: i'd be very wary of using TCP
21:05	@rusty	aliguori: yes.
21:05	aliguori	you'd have to tie into pam or something for authentication
21:05	aliguori	and i'm not sure you want to be doing that at that point in the stack
21:05	@rusty	aliguori: yes, "Someone Else's Problem".
21:05	aliguori	hehe
21:06	aliguori	rusty: ours actually, b/c we'll get a call from a customer quickly saying "we need to authenticate in xen with our active directory accounts"
21:06	@rusty	aliguori: are you interested in tackling the Domain <-> Registry communication mechanism?
21:06	@rusty	aliguiri: It's fairly simple to write a separate program which can dot hat.
21:07	aliguori	rusty: you mean the interdomain mechanism? i'm stretched way to thin right now but I can talk to Michael and see if we can divert some of our guys to help you out
21:07	aliguori	rusty: what's the general protocol look like? just a simple key query mechanism?
21:08	---	---> tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
21:08	aliguori	how do transactions work and how does the kernel interact with it?
21:10	@rusty	aliguori: I can do it if noone else is chomping at the bit...
21:10	@rusty	aliguori: ops are:
21:10	@rusty	int xr_daemon_open(void);
21:11	@rusty	nt xr_daemon_open_readonly(void);
21:12	@rusty	The Xen guys want a "struct xr_handle *" rather than an fd, but at the moment it's an fd.
21:12	@rusty	char *xr_directory(int fd, const char path, unsigned int *num);
21:12	@rusty	void xr_read(int fd, const char path, unsigned int *len);
21:12	@rusty	bool xr_write(int fd, const char path, const void data, unsigned int len,
21:12	@rusty	int createflags);
21:12	@rusty	bool xr_mkdir(int fd, const char *path);
21:12	@rusty	bool xr_rmdir(int fd, const char *path);
21:13	@rusty	bool xr_set_owner(int fd, const char *path);
21:13	@rusty	struct xr_permissions xr_get_permissions(int fd, const char path);
21:13	aliguori	rusty: i assume there's an option missing from xr_read?
21:13	@rusty	aliguori: no, why?
21:13	@rusty	int xr_set_permissions(int fd, const char *path,
21:13	@rusty	struct xr_permissions *perms,
21:13	@rusty	unsigned int num_perms);
21:13	aliguori	oh, it returns a void*
21:13	aliguori	i missed the star
21:14	@rusty	aliguori: yes. At the moment the interface lets you put in binary crap for contents, we may actually restrict that alter.
21:14	@rusty	bool xr_watch(int fd, const char *path, unsigned int priority);
21:14	@rusty	(The caller can then poll/seelct on the fd to see when a watch comes in).
21:14	@rusty	char *xr_read_watch(int fd);
21:15	aliguori	makes sense.. how's data persisted?
21:15	@rusty	Returns the path.
21:17	@rusty	Well, all these ops talk to the daemon, which keeps it currently in the filesystem.
21:17	@rusty	int xr_acknowledge_watch(int fd);
21:17	@rusty	Oops. Should be bool.
21:17	@rusty	bool xr_unwatch(int fd, const char *path, unsigned int priority);
21:18	@rusty	* transaction, and changes will not be visible to others until end.
21:18	@rusty	* Transaction only applies to the given subtree.
21:18	@rusty	Oops.. pasting comment didn't work.
21:18	@rusty	/* Start a transaction: changes by others will not be seen during this
21:18	@rusty	* transaction, and changes will not be visible to others until end.
21:18	@rusty	* Transaction only applies to the given subtree.
21:18	@rusty	* You can only have one transaction at any time.
21:18	@rusty	* Returns bool on failure.
21:18	@rusty	*/
21:18	@rusty	bool xr_transaction_start(int fd, const char *subtree);
21:19	@rusty	bool xr_transaction_end(int fd, bool abort);
21:19	@rusty	That's it.
21:19	@rusty	The functions all set errno.
21:20	aliguori	ok, this all looks pretty reasonable
21:20	@rusty	I didn'
21:20	@rusty	I didn't think it was contentious... seems to cover what people definitely want, and we can extend it later if reqd.
21:21	@rusty	Implementing permissions now, then working on watches, then transactions. First transaction implementation will probably be v. stupid.
21:21	aliguori	yeah, i agree. are you also developing a kernel-level api for the devices to use?
21:21	@rusty	aliguori: haven't yet, that's why I offered it to you 8)
21:21	aliguori	:-)
21:22	@rusty	aliguori: I think there needs to be a tool interface which tells the daemon about a new domain.
21:22	@rusty	OK, lunch is calling me, back in 30 mins.
21:22	aliguori	rusty: i had a long conversation about that with Harry Butterworth today
21:22	aliguori	rusty: alright, ttyl
21:23	---	User: *** rusty is now known as rusty_away
21:24	---	<<-- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit (Read error: Connection reset by peer)
21:24	---	---> tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
21:24	---	<<-- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit (Read error: Connection reset by peer)
21:46	---	<<-- niv [~nivedita@bi01p1.co.us.ibm.com] has quit (Quit: Quitting)
22:13	---	User: *** rusty_away is now known as rusty
22:17	---	---> N [~ca4bc809@webuser.thegrebs.com] has joined #xen
22:27	---	<<-- MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has quit (Quit: Connection interrupted by tinfoil hat)
22:46	---	<<-- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit (Quit: leaving)
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:52	---	<<-- matta-lt [~matta@69.93.28.254] has quit (Quit: Hey! Where'd my controlling terminal go?)
---	Log	closed Thu Apr 14 00:00:25 2005