THM 2005-05-19 Log D1116531352 Auriel (82.182.149.46) #! 14:40 should we take attendance? #! 14:40 howdy everyone. #! 14:40 could be worse ;) #! 14:40 hi #! 14:40 ron is not here yet, but he didn't confirm if he would come, so I think we probably should start... #! 14:40 how much longer do we want to give Ron to show up? #! 14:40 yo russ #! 14:41 okay. #! 14:41 we should make sure the logs and notes are available #! 14:41 i have pinged brz #! 14:41 that way latecomers can catch up #! 14:41 ericvh: lets start with the presentations and the status reports, if he comes he can read backlog... #! 14:41 kuroneko: yes, I'm logging #! 14:41 (if someone does too for backup, even better) #! 14:41 Okay, how do we want to handle order? #! 14:41 * kuroneko starts taking notes in acme. #! 14:41 alphabetically? #! 14:42 20h, you start :) #! 14:42 <__20h__> No, have to edit jacc. #! 14:42 __20h__: come on, what are you working on, and so on.. #! 14:43 <__20h__> Ok: 1.) Multiauthdom 2.) Modularisation of the Installer 3.) dtLinux v2.6 with v9fs #! 14:43 Where are you with (1)? #! 14:43 -!- rawhump [~tiitl@math.ut.ee] has quit ["Leaving"] #! 14:43 <__20h__> If ddr.9grid.de gets online again, then only factotum is the part missing. #! 14:43 -!- haraoka [~yoshiyuki@59.187.204.155] has joined #plan9 #! 14:44 -!- noselasd [~noselasd@80.239.96.162] has quit ["leaving"] #! 14:44 <__20h__> Authsrv and the backend are working. #! 14:44 __20h__: what is your plan? how does it compare to pressotto proporsal? #! 14:44 When you get a chance can you put something up on the wiki about how this works and where to get authsrv and the backend? #! 14:44 -!- noselasd [~noselasd@80.239.96.162] has joined #plan9 #! 14:44 <__20h__> The code is on my home CPUsrv and I won't release an alpha. #! 14:45 __20h__: can you at least give some coments on it's design? #! 14:45 <__20h__> uriel, I take the keys of the users on the other nodes and use them for the tickets. #! 14:45 so this is private key still? #! 14:45 <__20h__> Yes, it will be. #! 14:46 I think that's a mistake. If you're going to put in a new authsrv etc. and then be passing keys around, they should be public keys. #! 14:46 <__20h__> I want keyfs to be able to understand groups, so the node owner can create users for it. #! 14:46 <__20h__> So these can import the keyfs which does only export the keys. #! 14:46 That doesn't preclude public keys. #! 14:46 <__20h__> I mean /mnt/keys/$user/key; #! 14:47 Exporting keyfs means that now lots of auth servers have my key, instead of just one machine. This doesn't make me feel safer. #! 14:48 I just hate to see more work go into private key auth when it's just not the right solution -- we built factotum to have a convenient way to store public keys. #! 14:48 __20h__: any comments, any chance you an russ and maybe pressoto(and others interested in the matter) can discus this and come up to some greement? #! 14:49 <__20h__> No, uriel. #! 14:49 __20h__: any reasons? #! 14:50 <__20h__> No. #! 14:50 ok, lets move on then #! 14:50 Well, I'm glad this discussion is going so well. We should do this every day! #! 14:50 ;) #! 14:50 rsc9: heh #! 14:50 heh #! 14:50 axelB: ? #! 14:50 brz: "ozinferno is living on Vashon Island off Seattle where it is very tranquil. it will be in NJ in two weeks and then paris." #! 14:50 who's stepping up next? :) #! 14:51 better to keep things moving rather than getting into any in depth discussions anyways. #! 14:51 in-depth discussions are for the mailing list, not for this sort of meeting. #! 14:51 agreed #! 14:51 yes #! 14:51 axelB seems to be away #! 14:51 moving on, dho? #! 14:51 away too #! 14:51 uriel: check the idle times first. #! 14:51 if I skip someone let me know #! 14:51 ericvh: yes, I'm an idiot #! 14:52 he's in CA #! 14:52 ericvh next? :) #! 14:52 ericvh: I think it's your turn then :) #! 14:52 okay - 9grid.us is slowing coming to life, it's main purpose is going to be a host for people to drawterm to in order to check out plan9 versus any sort of real grid apps. #! 14:53 With luck, it'll be available after the weekend. #! 14:53 nice! #! 14:53 -!- dgil [~dgil@213.0.106.125] has quit ["Abandonando"] #! 14:53 the v9fs project is up to RC5 and the complaints from the pre-LKML communities seem to be diminishing, so RC5 will likely go to LKML on Monday. #! 14:53 cool, one question about the grids, falling short of multihost auth, any chance to have an standarized way to get accounts? #! 14:53 uriel: that's an in depth discussion for a mailing list. #! 14:54 ericvh: true, sorry.. #! 14:54 but its a good point, and something which should be discussed. I have no problem with authing off of sources though. #! 14:54 i was wondering how the sources account creation works #! 14:54 rsc9: ? #! 14:54 I have one of nemo's students (Gorka) showing up in mid-June to start working on 9P reliability stuff. #! 14:54 (wait for it uriel) #! 14:55 rsc9: is your app-space reliability stuff on sources somewhere? #! 14:55 * uriel tries to calm down, sorry, I'm really stressed #! 14:55 brz: you can also say that i'll IRC first week of june when in paris #! 14:55 Sources account creation works by interacting with a web server. You could just use sources accounts as your auth domain if you wanted. #! 14:56 rsc9: yes, I was wondering how httpd that runs as none can create accounts... #! 14:56 This summer there are two main projects for me: the reliability stuff and Linux kernel server support (which will likely be more than just u9fs as I want to be able to attach gateway devices, etc. directly to it). #! 14:57 There is a connection to a program in /srv that talks to a fossil fscons to create new accounts. #! 14:57 The other things that I'm interested in pursuing on the side is authsrv for Linux (already available?) and perhaps packaging plan9ports in a more Linux fashion (split up the components a bit so I can have people just grab the libraries and build environment to build synthetic file servers under Linux). #! 14:57 -!- mtgx [~mtgx@pD9553868.dip.t-dialin.net] has quit [Remote closed the connection] #! 14:58 * ericvh is finished now. #! 14:58 ok, should should we move on? #! 14:58 [let me catch up with my notes] #! 14:58 :) #! 14:59 rsc9: do you have any problem with me repackaging p9p? #! 14:59 I cant add a new user: if I use "disk/kfscmd 'newuser reezer'" It says "kfscmd: can't open commands file" #! 14:59 I was thinking direct ease of use: rpms and what not. #! 14:59 ericvh: short answer: no, long answer: let's talk elsewhere. #! 14:59 rsc9: sure.. #! 14:59 reezer: we are in a meeting now, please ask in #acme or wait until we are done #! 14:59 I'm interested in having a full fossil/venti like fileserver (or even ken-fs) hosted on LInux at some point. #! 15:00 ok #! 15:00 haraoka: ? #! 15:00 [it would have saved me some major headaches recently] #! 15:00 porting fossil should not be too hard. #! 15:00 seems a bit weird, but not hard. #! 15:01 -!- dgil [~dgil@213.0.106.125] has joined #plan9 #! 15:02 brz: ozinferno doesn't need much doc 'cause the vita stuff will largely do but i just ain't got the time #! 15:02 haraoka seems to be away(?) #! 15:02 Jim7J1AJH: your turn :) #! 15:03 no news. #! 15:03 Jim7J1AJH: ok :) #! 15:03 joe_c: now you! and you better be around! :) #! 15:04 future point of order: everyone that has something to say put themselves in the wiki, that way we don't go through this nonsense. #! 15:04 well, kuroneko, maybe you can start and see if they show up ;) #! 15:04 ok, my turn? #! 15:04 ericvh: no, it will create a ton of conflicts, just /msg me #! 15:05 okay, everyone else msg uriel if they have something to say. #! 15:05 kuroneko: yes #! 15:05 I'm just saying for the future, set agendas will control the chaos. #! 15:05 I've been working on sparc32 #! 15:05 [in particular, sun4m hardware support] #! 15:06 Is it working? #! 15:06 no progress in about 2-3 weeks, but its up to the point where promcalls vaugely work, the MMU can be mapped (but not reliably) #! 15:06 IOMMU code is still broken. #! 15:06 xalloc is broken #! 15:06 -!- dgil [~dgil@213.0.106.125] has quit ["Download Gaim: http://gaim.sourceforge.net/"] #! 15:06 I've just gotten my home standalone plan9 systems working in the last 24 hours (literally) #! 15:06 any comments on the xalloc plans? (/me remembers someting about it) #! 15:07 so I'll be moving my development onto them soon so I don't have to worry about vmware eating my code #! 15:07 I'm planning to rewrite xalloc #! 15:08 mostly because the initialisation for it is a pain in the ass. #! 15:08 and fixing it now will make other hardware ports easier. #! 15:08 keep jmk and me in the loop about your new xalloc design before you rewrite it. we both have been running into limitations (him on amd64, me on x86) #! 15:08 the main thing I plan to fix is removing the assumption that memory exists in two contiguous regions #! 15:09 * uriel should fish rsc9's comments on xalloc in 9fans a while ago and put them on the "future directions" wiki page... #! 15:09 and replacing it with something that can handle arbitary number of zones #! 15:09 kuroneko: if that's all your fixing i don't see why it needs a complete rewrite. don't fall into the cadt trap. #! 15:09 I don't plan a full rewrite yet. #! 15:10 just the initialisation stuff #! 15:10 and if that suffices, then it'll stay at that #! 15:10 rsc9: can you give us an idea of what limitations you and jmk have hit, and what would you like to see done about it? #! 15:10 that's an in-depth discussion #! 15:10 I'm on 9fans, so I'm happy to pick up comments there. #! 15:11 rsc9: ok :) #! 15:11 kuroneko: anything else? #! 15:11 longer term: general kernel device code cleanup stuff #! 15:11 kuroneko: did you find any problems trying the fs? #! 15:11 I need to try fs64 again #! 15:12 and I have patches for fs which people probably won't like. #! 15:12 rsc9: what is the stuatus of fs64 WRT the main distribution where AFAIK the intention is to deprecate everything that is not fossil/venti? :) #! 15:13 my fs patch(es) work around quirks in the IDL PL7100s i'm using #! 15:13 err, s/IDL/IDE/ #! 15:13 geoff seems to be happy to maintain ken's file server, and we have no problem with that, but bell labs is moving on. #! 15:13 One of the patches should be non-fatal #! 15:14 and should make the jukebox enumeration code a bit more robust #! 15:14 rsc9: any chance that if geoff wants his newer ken fs would be maintained/integrated into the BL distro? #! 15:14 the other patch is specific to these jukeboxes and isn't worth touching. #! 15:15 kuroneko: can you at least put that stuff in sources? it might be useful to someone who knows when... #! 15:15 I *should* document the entire build procedure from scratch #! 15:15 can somebody give me a writable directory in sources? #! 15:15 kuroneko: rsc9 ;) (it's kind of documented in the wiki how to get a sources account) #! 15:16 I've got a sources read account, not a writable directory... #! 15:16 if geoff sends us fs code we'll put it on sources. #! 15:16 rsc9: ok, I will talk with him then #! 15:16 kuroneko: that is what I was talking about #! 15:16 I personally think if Geoff is happy with fs64 being distributed, then fs should fall to fs64 #! 15:17 fs64 should be able to replace it #! 15:17 kuroneko: I'd like to see his work use sources as main repository, so things are not scatered all over the place, but I will bring it up with him and see what happens #! 15:18 I'd also like to see that there is only one active ken-fs so we don't get reduplicated effort #! 15:18 -!- deen [~deen@www.sevsky.net] has joined #plan9 #! 15:18 although, geoff and myself are probably the only people fighting with it at the moment thanks to fossil/venti #! 15:18 kuroneko: yes, absolutely, which is one of the reasons of keeping all work in a centralized place #! 15:19 hi #! 15:19 kuroneko: done? #! 15:19 I think thats all the important stuff. #! 15:19 gdiaz: you can take your turn now :) #! 15:20 (what are you doing, and what is the status, and so on) #! 15:21 oh, i only have tools for my own usage, that are no for general use (log parsers and so on that are useless for general public) #! 15:21 gdiaz: what about 9grid.es? #! 15:22 (and maybe your take on the whole cross-dom auth thing) #! 15:22 i've got 9grid.org es (i can't buy .es domain, i need to be a company for that), have the machine and public ip, but is stalled due to work load :( #! 15:23 next month i will have time to speak with 20h and start something more serious attempt about all cross-domain auth, etc #! 15:23 ok, anything else? #! 15:23 no :( (i am in need of support :) ) #! 15:24 gdiaz: what kind of support? #! 15:24 -!- haraoka [~yoshiyuki@59.187.204.155] has quit [Read error: 110 (Connection timed out)] #! 15:24 Major-Willard: your turn ;) #! 15:24 * Major-Willard has a bad hand -- accident on R&R #! 15:24 however #! 15:24 :) #! 15:25 i have been tweaking the compiler for large macro expansions #! 15:25 it's 99.9% done #! 15:25 the 0.1% is subtle #! 15:26 oh, are we in the dev meeting? #! 15:26 Major-Willard: it's all on sources? how much will it take to have it finished up and ready for production? #! 15:26 tmcm: yes :) #! 15:26 cmd/8c & cmd/cc are on contrib/boyd #! 15:26 Just what we need - large macro expansions. #! 15:26 i learnt a lot about the compiler #! 15:27 rsc9: did you (or anyone else for that matter) have plans to fix those minor buffer overflows from that french report a few weeks ago? #! 15:27 rsc9: please, lets try to be constructive(hell, even I'm trying to be constructive) #! 15:27 i ALSO decided that only a fool creates huge macros #! 15:27 afaict only like 1 or 2 were of any real consequence security-wise, but still... #! 15:27 tmcm: wait a sec, we are going by turns ;) #! 15:27 ahh, fuck it #! 15:27 tmcm: it's starred in my gmail. some day i'll get to it if no one else does. #! 15:28 ok #! 15:28 Major-Willard: ok, anything else? #! 15:28 i was being a little constructive. i'm glad boyd is fixing the limitations, i just agree that only a fool creates huge macros. #! 15:28 yeah, i been talking to brz about ozinferno #! 15:28 rsc9: I think we all agree on that one ;) #! 15:28 i'd be a lot happier if someone else took care of them though. a lot just change to snprint and it's done. #! 15:29 nope #! 15:29 rsc9: fixing the macro expansion is useful for the people taht are planning to move kencc to unix.. #! 15:29 yeah, or add an (if len <...) before the cpy #! 15:29 just use snprint. #! 15:29 any volunteers? #! 15:29 or strecpy. #! 15:29 nah #! 15:29 i'll see if i can knock a few out #! 15:30 time is tight right now :) #! 15:30 just change BUFSIZ and re-compile #! 15:30 tmcm: cool #! 15:30 was the report posted to 9fans? #! 15:30 yeah. #! 15:30 kuroneko: yes #! 15:30 * uriel has to look for it and put it on the wiki TODO #! 15:30 I might look at it when I get a chance then #! 15:31 * kuroneko has misplaced his fs patches #! 15:31 ok, nashi? #! 15:31 okay. #! 15:31 running tip9ug servers. #! 15:31 nashi: any issues with it? #! 15:31 talking about multi authdom in tip9ug too. #! 15:31 kuroneko: http://schtarb.free.fr/plan9.txt #! 15:32 is the url from the original report #! 15:32 * kuroneko adds to the notes #! 15:32 nothing particular so far. everyone behaves good on mordor. :) #! 15:32 nashi: :)) #! 15:32 nashi: aren't you working on some secret projects with vt3? #! 15:33 shhh! it's a secret. #! 15:33 :)) #! 15:33 what? are we doing some secret prj? #! 15:33 nashi: dunno, =) #! 15:34 anyway, i might be able to get a chance to do some p9 research as a part of my work. #! 15:34 cool #! 15:34 i would like to make some distributed venti system. or rather, venti proxy which fan out a write to multiple venti. #! 15:34 what would you use it for? #! 15:34 nashi: what about your security concerns BTW? #! 15:35 <__20h__> devfs over network. ;) #! 15:35 there's a bad idea. #! 15:35 kuroneko: are the notes you're taking somewhere live now? #! 15:35 it will work as a kind of oceanstore but one can do it far more easily by venti. #! 15:35 nashi: tmcm: no. they will be at the end. #! 15:36 ok. #! 15:36 i'm done. thanks. :) #! 15:36 nashi has also been discovering security issues with venti, working on japaneses fonts, and other things. he's being modest. #! 15:36 teletha is not running a httpd just yet, and is unlikely to be. #! 15:36 vt3: we know :) #! 15:36 how can there be security issues with a system that claims no security? #! 15:37 hehe. :) #! 15:37 rsc9: it would be nice to go from no-security into at-least-some-securty.. #! 15:37 then why do we need factotum if that were the case. #! 15:37 you don't need factotum for venti. #! 15:37 point taken #! 15:38 [I might have another converted developer to help the cause soon too - one of my friends will be likely looking into newsham's sparc64 port in more detail soon] #! 15:38 one might not notice that venti has no security. and there's a workaround to make it more secure. :) #! 15:38 in-depth discussion warning. #! 15:38 ok :) #! 15:38 noselasd: your turn #! 15:39 yeah. I think it something worth talking about though. We can extrapolate all the in-depth talking points from the notes and start 9fans threads on them. #! 15:39 uriel: eh ? I got nothing :-) #! 15:39 noselasd: ok then, bad, bad, have something ready for next time ;P #! 15:39 Oksel: you now! #! 15:40 argh, who knows where he is, I will hunt him down, ... #! 15:40 quintile: you then #! 15:41 blah, rmiller you I guess then :) #! 15:41 sorry i'm a irc newbie - is this working? #! 15:42 rmiller: :) #! 15:42 rmiller: yes :) #! 15:42 pretty busy with other stuff but I'll catch up with some usb storage improvements soon #! 15:42 uriel: oh - only point I can mention, is I made lcc generate assembly 8a mostly understood, which was nice until I realized 8a wasn't very fully featured to put it mildly :-) #! 15:43 rmiller: how difficult is usb attached disks (ipod) to support? #! 15:43 usb itself still needs some work because it is too slow to be really useable for storage #! 15:44 also lots of devices dont really obey the spec - haven't tried ipod yet #! 15:44 right #! 15:44 * Oksel is present! :) #! 15:44 rmiller: what would be needed to boot from usb storage #! 15:44 has anybody diced with the idea of implementing ieee1394 support? #! 15:44 kuroneko: I seem to recal some coment about it in 9fans some time ago #! 15:45 rmiller: do you know why usb is slow? i couldn't get past ~50kbyte/s #! 15:45 uriel: #! 15:45 -!- McLone [~mclone@ns.viso.tr.ukrtel.net] has quit [Remote closed the connection] #! 15:45 do we have a usb 2.0 driver yet? #! 15:46 Oksel: I know the immediate cause of slowness but not what causes that #! 15:46 rsc9: I can see that being a problem #! 15:46 rsc9: that would be nice, but if USB1 is slow, I don't see much point in aiming for 2.0, as the only real advantage is extra speed, and its' backwards compat #! 15:46 I seem to recall that the EHCI docos was hard to get in an open manner #! 15:47 Oksel: it is only able to send one packet per usb frame which is very limiting #! 15:47 rmiller: any idea how to go about it? #! 15:47 (btw, your comment about how to boot from usb storage din't show up :)) #! 15:48 uriel: forsyth may be looking at usb as well #! 15:48 rmiller: is that because of the way usb allocation work? smt like "reserve so many % for isochronous" and turn whatever is left over to bulk? i somehow got that idea, perhaps from you at twente9con #! 15:48 uriel: booting from usb should work if your bios supports it #! 15:48 rmiller: ah, cool #! 15:48 http://www.intel.com/technology/usb/download/ehci-r10.pdf #! 15:48 USB1.1 support would be very nice as all cheap USB devices seem to support that. #! 15:48 rmiller: 9load and the kernel don't care about it? #! 15:49 Oksel: no, that isnt it #! 15:50 perhaps someone at a uni has need for usb2? perhaps then i could implement it as thesis project or something, which should be coming up for me in a few months #! 15:51 uriel: not sure about 9load now, it's a while since I looked at it #! 15:51 rmiller: ok, thanks, I will investigate here when I have time, got some usb storage hardware recently.. #! 15:51 9load probably uses the bios? and the kernel can load usbfs for boot? #! 15:51 rmiller: anything else? any update on your smart card cool hacks? :) #! 15:52 Oksel: 9load is known for it's lack of intelligence and not being very good at speaking with bioses #! 15:52 sorry, with smart cards I'm still doing other stuff which I get paid for #! 15:53 rmiller: ok, your demo at 9con was very cool :) #! 15:53 uriel: thanks - maybe more one day #! 15:53 rsc9: ooh. ok. ehci is obviously no longer taboo #! 15:53 [if it ever was] #! 15:54 Oksel: ok, you can take your place now ;P #! 15:54 wow, thank you uriel #! 15:55 anyway, i am not doing much specific right now #! 15:55 i'm interested in looking at usb stuff #! 15:55 Oksel: lyar ;P #! 15:55 i modified usbd to automatically load usbmouse when a mouse gets plugged in #! 15:56 anyone want a more generic something for it? or thinks its bad? or should be done some way? #! 15:56 that way we could also get rid of the magic searching for unhandled devices in usb(audio mouse printer) #! 15:57 not that it's that magic #! 15:58 no comments? well, anything else? ;P #! 15:58 :D #! 15:58 Oksel: I guess that means you wont get stoned to dead if you send a patch for it ;P #! 15:58 * __20h__ gets a stone #! 15:59 "but all I said was that that piece of halibut was good enough for..." #! 15:59 Oksel: come on, I know you have been working on other stuff #! 15:59 quintile: heheheh.. #! 16:00 hum, well, cannot remember it right now? #! 16:00 not me either, oh well #! 16:00 quintile: we skiped you before, so... #! 16:00 oh, btw, don't know if it is well known already #! 16:00 http://marc.theaimsgroup.com/?l=9fans #! 16:01 which uriel made them put up #! 16:01 it's linked from the wiki #! 16:01 quintile: do you have anything to report then? (I hope so :)) #! 16:02 well, cifs - adding ntlmv2 auth, message signing, and dfs support, #! 16:02 extracting libasn1 from libsec - leading to ldapfs, snmpfs and kerberos in factotum (one day). #! 16:03 and chatfs as a /net service prtoviding msim, yahoo, jabber etc (ducks stone). #! 16:03 quintile: oh, where is that code? #! 16:03 quintile: I think it's about the third chatfs I hear of.. #! 16:04 all of the above are incomplete, if they where finished they would be published. #! 16:05 quintile: it would be nice to have even work-in-progress code in sources/contrib for people to poke at, but well, I know not everyone agrees with that #! 16:05 I would be happy to coperate with anyone who wants help but I am unhappy publishing half finished stuff. #! 16:06 quintile: puting things in sources/contrib is not publishing IMHO, but well.. #! 16:06 quintile: I may ping you on some of the auth stuff. #! 16:06 yes, ntlm, kerberos ? #! 16:07 dunno. Looking for more Linux solutions to v9fs auth. Kerberos was my immediate thought, but it may not be the best path. #! 16:08 you guys looked at inferno auth? #! 16:08 I also had some ideas about xdomain auth but people seemed to dislike my ideas. #! 16:08 krb5 might not be a completely meritless idea. #! 16:08 i agree #! 16:08 kerb5 - are we talking client or server here? #! 16:09 in the longer term, I'd say both. #! 16:09 * uriel dosn't understand why everyone seems to have different xdomain ideas and any kind of consensum or even dialog is impossible.. #! 16:10 uriel: Mmmm, #! 16:11 -!- nigelroles [~nigel@212.44.43.80] has joined #plan9 #! 16:11 hey nigelroles! #! 16:11 quintile: anything else? #! 16:13 a quastion: rsc9 sshv2 progress? #! 16:13 hi nigel. #! 16:13 sshv2 is a good question I guess, at least something very often asked by newbies #! 16:13 will email off-list. #! 16:14 wkj has an almost working sshv2 that i've done a little with. #! 16:14 I have an open field question actually: mips hardware support... #! 16:14 rmiller: why off-list? if I may ask? #! 16:14 has the cpu/term kernel ever run on SGI IP22 (Indy/ChallengeS/Indigo2) or DECStation? #! 16:14 er, rsc9 #! 16:15 because it's an in-depth discussion. #! 16:15 [as in MIPS DECStation] #! 16:15 list == #plan9 #! 16:15 rsc9: ok, could we get the code for that? maybe someone will fix it? #! 16:15 the code is not in a presentable form. #! 16:15 * uriel sighs #! 16:16 it's sshv2, who expects it to be presentable? #! 16:16 steve simon and i will talk off-list. i've been meaning to email him for a while. #! 16:16 -!- rminnich [~rminnich@65.242.93.132] has joined #plan9 #! 16:16 rsc9: ok #! 16:16 hey ron! #! 16:16 good morning #! 16:16 you are lucky, seems things are going slowly today :) #! 16:16 good, I am going slowly too. #! 16:16 okay rminnich: give us your status/on-going projects. #! 16:17 :) #! 16:17 it's the rest of us who are unlucky. #! 16:17 - making v9fs oops the kernel #! 16:17 * ericvh wonders if we can wrap this up in under 2 hours #! 16:17 - port to xen 3.0 #! 16:17 - working with vic zandy'x xcpu #! 16:17 - strongarm (on hold for a bit) #! 16:17 - try to work with k8 once jmk releases initial kernel code #! 16:18 status: #! 16:18 - v9fs oops on unmount :-) #! 16:18 rminnich: I have your bug starred in gmail, will be getting to it shortly - RCx focus has been on linux normal support, now that we've got that worked out, I'll be trying to get regressions going for plan9ports. #! 16:18 - xen 3.0 goes slowly #! 16:18 - xcpu is really really nice #! 16:18 - strongarm enet driver has issue (ha ha) #! 16:18 side topic: what is xcpu? and what happened to vic zandy - he's no longer at the labs, right? #! 16:19 zandy got tired of the labs, I think that the labs is more like my old for-profit lab I used to work for, it does not sound fun. #! 16:19 So he went to work at CCS in bowie, md, my old haunt. #! 16:19 I'm still hoping he will work with plan 9. #! 16:19 he did some very neat stuff. #! 16:19 and what is xcpu? #! 16:19 it's the thing everyone on the list hated so much :-) #! 16:19 ericvh: all signs point to no. #! 16:20 it's a server for remote execution #! 16:20 not released yet. #! 16:20 basically, it's for lightweight cluster nodes and is similar to the linux bproc stuff. #! 16:20 so the xcpu server presents 4 files and a dir to you #! 16:20 the dir is /proc from the machine xcpu runs on #! 16:20 to exec: #! 16:20 files it presents are #! 16:21 mach -- machine type -- read this file to read machine type (e.g. 'arm') #! 16:21 exe -- put executable files here #! 16:21 argv -- put argv here #! 16:21 ctl -- put commands here #! 16:21 so to run a proc on a node #! 16:21 import the xcpu service from the node #! 16:21 no in-depth discussions? #! 16:21 Sorry! #! 16:21 yeah, thats probably enough detail. :) #! 16:21 somebody asked :-) #! 16:21 I will stop :-) #! 16:22 [it does sound nice though] #! 16:22 rminnich: bad, you were right I at least woudln't like it ;P #! 16:22 what's the status on the 64-bit stuff rminnich? Or is that more of a jmk question? #! 16:22 xcpu kernels boot in xen in 1 second. #! 16:22 the compiler works #! 16:22 I think kernels are kinda happening. #! 16:22 but jmk is taking the opportunity to clean up the kernel a bit #! 16:22 "a bit"? #! 16:23