Back to Home / #xen / 2005 / 04 / Prev Day | Next Day
#xen IRC Logs for 2005-04-13

---Logopened Wed Apr 13 00:00:47 2005
00:13itamarjp '[root@router conacci]# e2fsck -f root_fs.ext3 -y
00:13itamarjp e2fsck 1.36 (05-Feb-2005)
00:13itamarjp Pass 1: Checking inodes, blocks, and sizes
00:13itamarjp Pass 2: Checking directory structure
00:13itamarjp Pass 3: Checking directory connectivity
00:13itamarjp Pass 4: Checking reference counts
00:13itamarjp Pass 5: Checking group summary information
00:13itamarjp root_fs.ext3: 53583/128000 files (0.2% non-contiguous), 140324/256000 blocks
00:13itamarjp [root@router conacci]# dd if=/dev/zero of=root_fs.ext3 bs=1 count=1 seek=40G conv=notrunc
00:13itamarjp 1+0 records in
00:13itamarjp 1+0 records out
00:13itamarjp [root@router conacci]# resize2fs -p root_fs.ext3
00:13itamarjp resize2fs 1.36 (05-Feb-2005)
00:13itamarjp resize2fs: File too large while trying to determine filesystem size
00:13itamarjp [root@router conacci]#
00:13itamarjp [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:13mael hi
03:16muli_ hello mael
03:17--- <<-- DEac- [~deac@xdsl-213-196-196-194.netcologne.de] has quit (Ping timeout: 480 seconds)
03:28murb anyone seem stuff like panic: HYPERVISOR_mmu_update failed
03:29--- ---> DEac- [~deac@xdsl-84-44-151-129.netcologne.de] has joined #xen
03:29murb 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:18mael MarkWilliamson: wow
06:18mael I'm impressed
06:18MarkWilliamso| mael: oh?
06:18mael I thought you would come around 8pm after being up so late yesterday :)
06:18MarkWilliamso| I thought you might say that :-)
06:19mael thanks for your answear on the L4 vs. xen issue
06:19MarkWilliamso| today is unusually early... i don't like mornings :-)
06:20mael hehe I don't either
06:21mael I read the safe hardware access paper yesterday
06:21mael It is very interesting
06:21mael some of my questions found answears
06:21hebutterworth| Mark, quick question about protocol:
06:22MarkWilliamso| yup
06:22hebutterworth| Are the driver status down messages notification that the driver is down
06:22hebutterworth| or are they requests for xend to take the interfaces down so that the driver can exit cleanly?
06:23MarkWilliamso| I think they're the former, hang on
06:27MarkWilliamso| Well the driver status UP messages are notifications that the driver is here and it wants Xend to talk to it
06:27MarkWilliamso| so I think the DOWN messages are the inverse
06:28MarkWilliamso| i.e. the former of your statements
06:28hebutterworth| 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:29MarkWilliamso| 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:30hebutterworth| OK. So what about unloading the back end module?
06:31hebutterworth| The back-end could stop using all shared pages then send a driver status down.
06:31hebutterworth| 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:31MarkWilliamso| I think the backend should probably send close, then disconnect messages for all the interface
06:32hebutterworth| The back-end doesn't ever send any messages like that.
06:32hebutterworth| There aren't any.
06:33MarkWilliamso| what i meant to say was "cause to be sent to the front end"
06:34MarkWilliamso| of course, it depends what you want this to look like to the front ends
06:34hebutterworth| So I was thinking that the back-end would cease to use all shared resources then send a back-end driver down message
06:34MarkWilliamso| yeah, that sounds reasonable.
06:34hebutterworth| Then xend would send an fe interface status destroyed to the front end
06:35MarkWilliamso| ^ i.e. do the frontends see a backend driver domain restart, or the complete removal of the interface
06:36hebutterworth| How did the sequencing work for restartable driver domains that was written up in one of the papers I read?
06:37hebutterworth| Was that actually implemented?
06:37MarkWilliamso| if you (the frontend) get a DISCONNECTED message when you were CONNECTED then you expect it's a backend restart
06:38hebutterworth| OK
06:38MarkWilliamso| you then run the state machine as normal to make a new connection
06:38MarkWilliamso| the code i put into the 2.4 driver for supporting suspend / migration should cope with this (or be pretty close)
06:40MarkWilliamso| 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:40hebutterworth| So, I guess one question then is whether a back end driver module unload should look like a driver domain restart
06:40hebutterworth| Maybe it should.
06:40MarkWilliamso| Xfrd is rather complicated and its difficult to trace exactly what's breaking it right now
06:40MarkWilliamso| it probably depends! ;-)
06:41MarkWilliamso| probably just notifying the frontend if a new backend is loaded might work
06:43hebutterworth| The only difficult thing about writing the code is trying to work out what behaviour you want.
06:44MarkWilliamso| you're in uncharted territory here - we don't have a standard to work to because we don't have any unloadable modules
06:45hebutterworth| OK. Well, I'll think more about it.
06:45MarkWilliamso| 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:45MarkWilliamso| and then we would have a standard :-)
06:46MarkWilliamso| I need to go eat, etc, now or I won't be very useful. See you later.
06:46* MarkWilliams goes
06:46hebutterworth| 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:08riel Failed update VA mapping: bf9e1f48, 03696067, 00000000
09:08riel ------------[ cut here ]------------
09:08riel kernel BUG at include/asm-xen/hypervisor.h:484!
09:08riel awww crud
09:09riel dom0 works great, though
09:11@Sir_Ahzz heh
09:15riel 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:16eigood Sir_Ahzz: I've got debs of iscsi enterprise target
10:16eigood including a proper kernel module source deb
10:18--- ---> yazid_work [~chatzilla@blaubaer.iehk.RWTH-Aachen.DE] has joined #xen
10:20yazid_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:41eigood use ebtables
10:41eigood and bridging
10:41mael eigood: he left :)
10:43eigood 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:06eigood 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:21rusty 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:30niv rusty: anthony's probably gone for food -they had a mtg upto 6:30PM Austin local time
19:34niv 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:35niv 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:36niv 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:39niv 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:40niv 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:40rusty niv: Oh, OK. I've been trying to catch hi,
19:40niv allrighty, give me a few
19:54niv MarkW: still broken :(
19:54@MarkW niv: interesting. did you try it in a domU or in dom0?
19:54niv domU
19:54niv er, typo, dom0
19:55niv rebooting and trying in domU
19:55niv solid hang
19:55@MarkW OK. Thanks for checking it out.
19:55@MarkW It's weird.
20:04aliguori rusty: hey rusty
20:05--- <<-- jeroney [~jeroney@pixpat.austin.ibm.com] has quit (Remote host closed the connection)
20:05aliguori 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:20aliguori 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:32aliguori MarkW: exciting! when do we get to see the source? :-)
20:32aliguori 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:34aliguori :)
20:42rusty 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:50aliguori 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:52rusty aliguori: well, it can speak to tools locally (sockets) and also using some (handwave!) mechanism to the domains.
20:52rusty aliguori: fairly simple interface, twists include permissions (for domains) and transactions.
20:52niv rusty: af_unix or af_inet?
20:53rusty niv: af_unix for the moment. af_inet means I have to worry about endianness, which I can do later.
20:53niv rusty: agreed
20:54rusty 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:54rusty niv: for TCP sockets, we need some auth system.
20:54niv 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:55rusty 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:57niv 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:05aliguori rusty: i'd be very wary of using TCP
21:05@rusty aliguori: yes.
21:05aliguori you'd have to tie into pam or something for authentication
21:05aliguori 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:05aliguori hehe
21:06aliguori 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:07aliguori 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:07aliguori 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:08aliguori 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:13aliguori 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:13aliguori oh, it returns a void*
21:13aliguori 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:15aliguori 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:20aliguori 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:21aliguori 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:21aliguori :-)
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:22aliguori rusty: i had a long conversation about that with Harry Butterworth today
21:22aliguori 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?)
---Logclosed Thu Apr 14 00:00:25 2005