[00:16:04] --- shadow@gmail.com/barnowlCA9FC336 has left [00:16:13] --- shadow@gmail.com/barnowlCA9FC336 has become available [02:02:09] --- Simon Wilkinson has become available [02:19:41] --- kula has left: Lost connection [02:53:19] --- Simon Wilkinson has left [02:53:46] --- Simon Wilkinson has become available [03:09:08] --- kula has become available [03:24:28] --- Simon Wilkinson has left [03:36:41] --- shadow@gmail.com/barnowlCA9FC336 has left [03:36:50] --- shadow@gmail.com/barnowlCA9FC336 has become available [05:25:16] --- Dan has become available [05:28:13] --- meffie has become available [05:30:10] --- meffie has left [05:31:09] --- meffie has become available [06:00:29] --- Simon Wilkinson has become available [06:05:22] --- Simon Wilkinson has left [06:05:37] --- Simon Wilkinson has become available [06:10:24] --- Simon Wilkinson has left [06:11:48] --- Simon Wilkinson has become available [06:14:20] --- Stephan Wiesand has become available [06:18:32] --- kula has left [06:19:35] --- kula has become available [06:19:56] --- Simon Wilkinson has left [06:20:24] --- Simon Wilkinson has become available [06:27:23] --- Simon Wilkinson has left [06:27:31] --- Simon Wilkinson has become available [06:27:48] --- Simon Wilkinson has left [06:28:38] --- Simon Wilkinson has become available [06:34:19] --- Stephan Wiesand has left [06:34:19] --- shadow@gmail.com/barnowlCA9FC336 has left [06:34:23] --- shadow@gmail.com/barnowlCA9FC336 has become available [06:35:18] --- Stephan Wiesand has become available [06:43:09] --- Ken Dreyer has become available [06:47:30] --- Simon Wilkinson has left [06:47:44] --- Simon Wilkinson has become available [06:48:02] --- Simon Wilkinson has left [06:48:21] --- Simon Wilkinson has become available [07:09:27] --- deason has become available [07:35:20] --- Simon Wilkinson has left [07:35:27] --- Simon Wilkinson has become available [07:54:20] the solaris 11 buildslave stopped responding sometime yesterday, I think; gerrit verification is a little delayed, but it's back up now and building [08:05:35] --- Simon Wilkinson has left [08:07:34] --- Simon Wilkinson has become available [08:12:04] --- Stephan Wiesand has left [08:16:28] --- Dan has left [09:09:56] --- jaltman/FrogsLeap has left: Disconnected [09:15:50] --- jaltman/FrogsLeap has become available [09:38:41] --- Simon Wilkinson has left [09:39:49] Is RAND_bytes() the right API to get cryptographic-strength random data in userland? [09:46:28] --- Dan has become available [09:53:55] --- Dan has left [10:16:39] --- Simon Wilkinson has become available [10:44:58] why does aix hate me? [10:45:24] we all ask ourselves that sometimes [10:45:36] details? [10:45:50] heh. gerrit 8911 [10:48:38] you failed to export those [10:48:49] src/vlserver/*sym needs them [10:49:10] (and this is apparently the first userland tool that uses them) [10:49:34] AIX is the only platform that uses the symbol maps even when building static binaries [10:50:29] (which imo is a service) [10:50:35] Speaking of symbol maps, should afs_xdr_u_int be in liboafs_rx.la.sym? [10:50:41] (It is currently not.) [10:52:01] so, aix is actually trying to be my friend, and i've spurned, how shameful. [10:52:41] aix loves you. at least while you're looking [10:54:15] kaduk: If we use xdr_u_init, then it should be. But when I built those export lists, nothing was using it. [10:55:51] Okay. I added it for my rxgk code which uses it, but I think I want to switch to using explicit-width types eventually anyway. [10:56:03] I don't think your rxgk code should be using it [10:58:44] All of our other XG files use the afs_ types - rxgk really should be using those too. [10:59:28] Yup. [10:59:40] kaduk, since you are in implementation, does that mean you think the draft 03 can be submitted? [11:00:43] meffie: I guess so. Sorry I didn't reply to your mail; I spent 30+ hours doing http://tech.mit.edu/V132/N62/mitsfs.html last weekend and haven't cleared my mail backlog yet. [11:01:02] I do think we'll want to place length limits on the various variable-length arrays before we go final, though. [11:03:43] ok, thanks, we do have a backlog of specs to do, many of them are going to be far quicker than rxgk, but obviously, rxgk has priority. [11:03:43] --- Ken Dreyer has left [11:06:37] --- Ken Dreyer has become available [11:08:05] I think we can probably submit a draft-03, but I don't think its done yet. I think there's still some concerns around the way we describe the meanings of the various errors, and how they are responded to. [11:08:20] And we also need to do afs3-rxgk, which you can't really do an implementation without [11:08:36] That, too. [11:08:51] (Did you ever find those patches to rxgk-afs?) [11:10:56] Did I not send you them? [11:12:43] yes, afs3-rxgk is next on the list. [11:13:21] It doesn't make sense to progress them independently. Once we're done with afs3-rxgk, we'll need to revisit the base rxgk document [11:13:55] ouch. [11:14:33] I don't remember getting them, though I suppose I could have missed it. [11:14:34] That's what I was saying during the CombineTokens discussion - we can't decide on the split in content between the two documents until we've actually reviewed both documents [11:16:54] well, how about we submit the draft-03 now, as it stands, and move on to afs3-rxgk? [11:18:53] we can then promote both to experimental at the same time. [11:19:44] (although in theory, they should be independent) [11:20:02] Well, rxgk-afs depends on rxgk! [11:20:04] They're not independent. afs3-rxgk makes no sense without rxgk [11:21:08] Anyway, what I'm currently implementing is basically just stubs for the client/server half of the two RPCs; it's not integrated with openafs at all other than using the other (rx, etc.) infrastructure. [11:21:24] er, yes, i meant rxgk should not be dependent on afs3-rxgk. [11:24:10] It's so long ago that I wrote the YFS implementation, I can't remember what order I did it n! [11:24:37] heh. fair enough. [11:25:14] But rxgk itself is tiny - it's the hooks with the rest of OpenAFS that are a total pain [11:25:36] so, ben, other than the length limits, do you know of anything else preventing a draft 03 rxgk i-d ? [11:25:51] Nope. [11:25:58] yay [11:26:01] And I don't think we need to wait on those lengths for a -03. [11:26:08] Were Jeffrey's error code concerns addressed? [11:26:18] I don't think we have to wait on lengths for −03 either [11:26:32] I don't think I ever found the mail with Jeffrey's concerns, actually. [11:27:09] From memory, he wanted language describing when an implementation should send a particular error message, and what the reaction to receiving each message should be. [11:28:27] I think that https://github.com/kaduk/openafs/commit/ac793f588b84f97038b433d61e3b43e9279fc547 is the current state of that. [11:28:44] I'm less bothered than he is, because I think the errors are just informational. [11:28:56] But I don't know that anyone has reviewed it. [11:29:13] (Not that lack of review prevents issuing a new i-d!) [11:29:26] The client response to any error should be "give up", and the client should be able to discern why from the negotiation [11:30:28] Did the whole what errors go in aborts, and what in payload get resolved in any way? [11:30:40] (the text in that commit looks good, apart from that) [11:31:02] We don't have anything in the document about splits between aborts and payloads. [11:32:49] I think we should, but again, it's probably not worth not doing a draft for. [11:33:04] Sure. [11:34:05] I'm back properly tomorrow - I'll have a look at doing a new draft then [11:34:17] Yay [11:34:23] excellent. thank you simon. [11:34:25] Thanks [11:35:12] ben, will you then revive the afs3-rxgk i-d? [11:35:44] Yup. I hadn't done much with that since I didn't get (or failed to see) the extra patches from Simon. [11:35:47] That one is going to be more fun. This document already reached working group consensus once, so was in a better shape [11:36:08] I know Andrew has concerns about the callback protection stuff, in particular [11:37:08] yes, but i recall that document more concrete(?) [11:38:12] Not sure what you mean by more concrete? [11:38:55] just my impression from way back when i first read it. [11:39:37] --- Brandon Allbery has left [11:39:46] --- allbery has become available [11:39:48] Nothing we've changed in the base document has major effects on the implemented protocol. The stuff we need to discuss for the afs3 document may well result in protocol changes - in particular, if we decide to modify the way that callback protection is done [11:42:45] --- allbery has left [11:42:49] --- ballbery has become available [11:47:16] --- meffie has left [12:00:04] --- Simon Wilkinson has left [12:06:55] --- mmeffie has become available [12:11:19] --- mmeffie has left [12:11:19] --- mmeffie has become available [12:12:49] --- mmeffie is now known as meffie [12:57:53] --- kula has left [12:58:27] --- kula has become available [14:09:48] --- Simon Wilkinson has become available [14:30:58] --- mdionne has become available [14:53:51] --- mdionne has left [14:56:00] --- meffie has left [15:29:34] --- mdionne has become available [15:45:56] --- mdionne has left [16:31:44] --- deason has left