[02:09:39] --- Stephan Wiesand has become available
[02:33:20] <Simon Wilkinson> They're two separate changes so should remain distinct.
[03:11:04] <Simon Wilkinson> I've got a load of review comments on the RX one - but that should probably wait until it hits gerrit
[06:03:18] --- meffie has become available
[06:09:40] --- squinney has become available
[06:27:12] <kaduk@mit.edu/barnowl> Simon: Thanks.  Yeah, the idea was to not submit to gerrit until I
actually thought it was ready.
[06:47:26] --- shadow@gmail.com/barnowl5ABA57FD has left
[06:47:35] --- shadow@gmail.com/barnowl5ABA57FD has become available
[07:16:43] --- deason/gmail has become available
[07:17:07] <Simon Wilkinson> kaduk: Specifically: You should get rid of rx_SetEpoch, rx_SetConnectionEpoch and rx_SetConnectionId
[07:17:15] <Simon Wilkinson> And the epoch lock
[07:18:43] <Simon Wilkinson> And then just set rx_epoch and rx_nextCid to suitably chosen random values in rx_InitHost
[07:28:40] --- squinney has left
[07:31:13] <kaduk@mit.edu/barnowl> Fair enough.
I was planning on getting rid of the Cuid global, at least :)
[07:31:57] <Simon Wilkinson> One thing to bear in mind (for both this and rxgk) is that not all of our supported platforms have random support in kernel.
[07:32:14] <Simon Wilkinson> On some, calling into hcrypto's random functions will segfault.
[07:32:37] <Simon Wilkinson> Oh, and don't use RAND_bytes. 
[07:33:20] <Simon Wilkinson> osi_readRandom() is a better bet, as if there is native randomness support in the kernel, it will just use that.
[07:33:22] <kaduk@mit.edu/barnowl> > calling into hcrypto's random functions will segfault
Um.  Goody.
[07:34:28] <Simon Wilkinson> For platforms with no native random support, you need to provide a new upcall through afsd to seed hcrypto's fortuna RNG.
[07:37:04] --- meffie has left
[07:41:32] <kaduk@mit.edu/barnowl> Do you remember which platform(s) are in that situation?
[07:41:59] <Simon Wilkinson> IRIX and AIX, I think. Nothing mainstream.
[07:42:48] <kaduk@mit.edu/barnowl> Hmm.  I have this O2 sitting under my desk that I keep threatening to
do something with...
[07:42:50] <Simon Wilkinson> Anything without an implementation of osi_readRandom
[07:43:07] <kaduk@mit.edu/barnowl> git grep finds an osi_readRandom in IRIX, though.
[07:43:32] <Simon Wilkinson> Yeah. It just calls osi_Panic(), though, IIRC.
[07:43:46] <kaduk@mit.edu/barnowl> Ah.  Yes, it does.
[07:45:13] <Simon Wilkinson> I seem to recall that Irix and AIX both have all of the stuff you need, it's just that none of it is exposed to kernel modules. So the fix is just to make afsd grab a hunk of randomness in userspace, and stuff it into the kernel as part of cache manager startup
[07:45:42] <kaduk@mit.edu/barnowl> That seems perfectly plausible, just annoying.
[07:47:06] <Simon Wilkinson> Yeah, that pretty much sums up Irix and AIX.
[07:47:17] <kaduk@mit.edu/barnowl> Heh :)
[07:48:15] <kaduk@mit.edu/barnowl> Have you gotten to look at more of the changes in rxgk-04?
I suspect that few people have had time to look at it, given the lack
of comments...
[07:49:43] <Simon Wilkinson> I haven't had a chance to look yet. I found pretty much the same when I was pushing new document releases - although the comment cycle I saw was more like every 6-12 months.
[07:50:26] <kaduk@mit.edu/barnowl> Maybe I will send a git log to the list, that seems to have spurred
comments in the past (at least sometimes).
[07:50:53] <Simon Wilkinson> It's not clear yet whether YFS are going to ship with a rxgk-04 compatible implementation, or one that's compatible with an earlier release of the document.
[07:51:12] <Simon Wilkinson> If we're doing rxgk-04, I'll definitely get a chance to look. If we're not, it may take longer...
[07:51:15] <kaduk@mit.edu/barnowl> *nods*
[08:24:29] <kaduk@mit.edu/barnowl> Simon: Do you think that worrying about the undefined behavior on
overflow of rx_nextCid is worth doing?
[08:28:21] <Simon Wilkinson> If rx_nextCid is random, then yes.
[08:52:42] <kaduk@mit.edu/barnowl> I think I'm going to keep the nextcid update logic in a separate
function, as the overflow check is kind of bulky to put in
NewConnection directly.
[09:17:09] <kaduk@mit.edu/barnowl> Hmm, but osi_readRandom is in afs/afs_prototypes.h which we don't want
the rx stack pulling in...
[09:18:00] <kaduk@mit.edu/barnowl> (Or is it okay in the kernel?)
[09:18:35] <Simon Wilkinson> That should be fine in the kernel. The kernel include tree is a mess.
[09:19:34] <Simon Wilkinson> Okay. Wrong steer. Use RAND_bytes 
[09:19:49] <Simon Wilkinson> (In userspace that will go to hcrypto, in the kernel, to osi_readRandom)
[09:20:00] <kaduk@mit.edu/barnowl> For both userland and kernel?
It should be easy to condi--
Oh, okay.
[09:20:23] <kaduk@mit.edu/barnowl> It still feels weird that 1 is success for RAND_bytes, but *shrug*.
[09:20:37] <Simon Wilkinson> I think that's probably the OpenSSL API
[09:21:00] <Simon Wilkinson> (Bascially, hcrypto has the same API as OpenSSL, so you can drop in OpenSSL instead if you are sufficiently license-blind)
[09:46:35] <Simon Wilkinson> Happy to discuss the rxgen size thing here, in parallel if folk want to.
[09:49:44] <kaduk@mit.edu/barnowl> New RPCs that allow iteration would have to go through the standards
process, though, right?
[09:50:15] <Simon Wilkinson> Yes, and probably get blocked behind everything else that's happening there. So not a speedy solution
[10:39:03] --- Stephan Wiesand has left
[10:39:28] --- Stephan Wiesand has become available
[10:39:32] --- Stephan Wiesand has left
[11:00:13] <kaduk@mit.edu/barnowl> Simon: my github 'epoch' branch is updated.  Not going to submit to
gerrit until I have a story for not panicing the kernel.
[13:43:06] --- mvita has become available
[13:44:45] --- mvita has left
[13:44:45] --- mvita has become available
[16:59:34] --- deason/gmail has left
[19:37:19] --- mvita has left