--- Day changed

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