[02:09:53] --- squinney has become available
[04:33:42] --- squinney has left
[04:42:35] --- squinney has become available
[05:24:12] --- squinney has left
[05:24:18] --- squinney has become available
[07:17:11] --- Stephan Wiesand has become available
[08:19:07] --- squinney has left
[08:20:33] --- Stephan Wiesand has left
[08:25:20] --- meffie has become available
[08:26:53] --- ballbery has become available
[09:01:01] --- deason has become available
[10:00:42] --- kula has become available
[10:43:02] <kaduk@mit.edu/barnowl> Re 9136 does that constant want to not be a literal?
[10:48:04] <Simon Wilkinson> kaduk: Which constant are you referring to?
[10:48:25] <kaduk@mit.edu/barnowl> 04000
[10:48:38] <kaduk@mit.edu/barnowl> (I only looked at the email so far)
[10:49:05] <kaduk@mit.edu/barnowl> But it sure looks like it is supposed to be a particular bit, and
maybe ought have a symbol for it
[10:49:36] <Simon Wilkinson> The change is really just fiddling with the code so that clang doesn't moan about it. Basically doing bitfield &= ~blah trips compiler errors that doing bitfield = bitfield & ~blah doesn't.
[10:49:49] <kaduk@mit.edu/barnowl> Right.
[10:50:15] <kaduk@mit.edu/barnowl> Unrelatedly, it seems to usually be a good idea to use defined
constants instead of magic numbers.
[10:50:17] <Simon Wilkinson> They should probably be S_ISUID and S_ISGID
[10:50:26] <Simon Wilkinson> But that's a different change ...
[10:50:36] <kaduk@mit.edu/barnowl> Right, it's a different change.
[10:51:34] <Simon Wilkinson> (also, whilst they look like OS mode bits, they're actually internal mode bits. I don't know if there's any guarantee that those defines will always have those values)
[10:52:12] <kaduk@mit.edu/barnowl> Well, we could have our own defines, I suppose.
[11:03:22] <kaduk@mit.edu/barnowl> Will 1 ever be allowed as an rx error code?
[11:04:18] <kaduk@mit.edu/barnowl> (Well, GSS_S_CONTINUE_NEEDED, really)
[11:21:19] <Simon Wilkinson> I wouldn't rely on it not appearing as an RX error code.
[11:22:11] <Simon Wilkinson> Also - GSS_S_CONTINUE_NEEDED _isn't_ an error, so having it be transmitted as an RX abort would not be a good thing.
[11:22:35] <kaduk@mit.edu/barnowl> True.
[11:23:14] <Simon Wilkinson> (Certainly, in rxgk, all of the gss status codes are passed as parameters, rather than as return codes)
[11:24:01] <kaduk@mit.edu/barnowl> I'm re-rewriting the client GSS negotiation loop, and I want to
condense a bunch of different cases into a single variable, which
might indicate an RX error or a GSS error.  I think it's easiest to
just use a flag value to indicate that there is a GSS error (so the
caller can consult the GSS status if desired), and if that flag value
is received as an RX error, remap to RXGK_INCONSISTENCY.
[11:25:15] <kaduk@mit.edu/barnowl> I could define RXGK errors for these cases, I suppose.
[11:27:20] <Simon Wilkinson> That sounds over complex, but I guess we can cross that point when it comes to review.
[11:27:27] <kaduk@mit.edu/barnowl> Not sure it's worth it, though.
[11:28:06] <Simon Wilkinson> I don't think the caller should ever be aware of the underlying GSS library.
[11:28:40] <Simon Wilkinson> So, the caller shouldn't ever see GSS error codes.
[11:28:50] <kaduk@mit.edu/barnowl> Well.
[11:29:24] <kaduk@mit.edu/barnowl> The case at present is a subroutine which is the body of the loop,
called from an outer get_token() routine that has the loop logic.
[11:29:35] <kaduk@mit.edu/barnowl> So it is still internal, but nor does it need to see a GSS error.
[11:30:29] <Simon Wilkinson> Yeah, we have something pretty similar.
[11:31:03] <Simon Wilkinson> What the library does internally isn't that important - the critical thing is that the caller (to the token acquisition routine) can't be expect to be linking against the same GSS library as rxgk is linked against.
[11:32:11] <kaduk@mit.edu/barnowl> Right.
[11:32:37] <kaduk@mit.edu/barnowl> (I don't comply to this right now for other reasons right now, of
course.)
[11:41:41] <kaduk@mit.edu/barnowl> get_token_round_trip() is the subroutine in question, here:
https://github.com/kaduk/openafs/blob/9d8909d498898ba937077d74baa95ed633ca7e5f/src/rxgk/ndebug.c
[12:49:31] <kaduk@mit.edu/barnowl> Anyone seeing bosserver segfaults on master?
[12:53:09] <Simon Wilkinson> I don't run the OpenAFS bosserver, so I can't really say there. Chas has been doing a lot of work on the bosserver, though.
[12:54:57] <meffie> i'm running bosserver master, havent seen any crashes.
[12:57:08] <Simon Wilkinson> Linking the bosserver with anything pthreaded won't end well, though...
[12:57:40] <Simon Wilkinson> Or with anything that calls sleep() or select(), come to that
[13:12:35] --- mvitale has become available
[13:20:17] --- meffie has left
[13:48:27] --- mdionne has become available
[14:35:43] --- ballbery has left
[14:54:15] --- Simon Wilkinson has left
[15:05:55] --- Simon Wilkinson has become available
[16:17:52] --- deason has left
[17:08:54] --- mvitale has left
[17:15:49] --- mvitale has become available
[18:43:20] --- mvitale has left
[18:45:25] --- jaltman/FrogsLeap has left: Disconnected
[18:51:08] --- mdionne has left
[18:51:40] --- jaltman/FrogsLeap has become available
[21:45:44] --- jaltman/FrogsLeap has left: Disconnected