- Wednesday, July 30, 2014

release-team@conference.openafs.org

Wednesday, July 30, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[06:16:55] Jeffrey Altman leaves the room
[06:51:45] Jeffrey Altman joins the room
[12:31:21] wiesand joins the room
[13:58:08] meffie joins the room
[14:03:21] Marc Dionne joins the room
[14:05:10] <wiesand> Hello.
[14:05:21] <wiesand> Marc, have you tested against 3.16-rc7 yet?
[14:06:08] <Marc Dionne> hi stephan - yes, running with rc7+ currently
[14:06:25] <wiesand> Great. No further changes needed?
[14:06:42] <Marc Dionne> no, i don't expect there will be anything else needed
[14:06:58] <Marc Dionne> possible release this weekend, probably next weekend at the latest
[14:08:03] <wiesand> Thanks. It seems we'll have  a 1.6.9.1 release.
[14:08:23] <Marc Dionne> Al Viro hasn't been around, so not much queued up for 3.17 yet, which means probably things will be quiet for 3.17
[14:08:33] <wiesand> Good news.
[14:10:17] <wiesand> 11320 looks like a candidate for 1.6.9.1 to me?
[14:11:31] <Marc Dionne> yeah 11320 would be good to get in
[14:12:29] <Marc Dionne> and maybe 11316, which i should look at more closely
[14:13:23] <wiesand> Right, that's a another candidate.
[14:13:40] <Marc Dionne> but i don;t know if you expect a 1.6.9.x to only have compatibility fixes
[14:13:44] kaduk joins the room
[14:14:47] <kaduk> I see meffie has addressed Andrew's concerns about the stack-reduction patchsets (for master only, so far).
[14:15:12] <wiesand> The last such release had client fixes for selected platforms. And I think that was a success.
[14:15:53] <wiesand> When you run the latest kernel, you're riding the bleeding edge anyway.
[14:15:54] <meffie> yeah, i can do 1.6.x gerrits if those hit master. also trying to catch up on the volscan-1_6 patches.
[14:16:31] <kaduk> Does that mean you have time to issue new internet-drafts, too? ;)
[14:16:49] <meffie> yeah, that too.
[14:17:00] <wiesand> Cat twenty-too...
[14:19:55] <kaduk> I ran into some "interesting" behavior a few days ago, though I think it's master-only...<more>
[14:21:36] <kaduk> Our struct rx_opaque has a size_t for the length field, which can be/is 64-bits on 64-bit platforms.  But, the marshalling code emitted by rxgen casts the pointer to rx_opaque->len to a pointer to u_int; this caused my kernel module to write only to the low 32 bits of the length (this is a little-endian machine), leaving the high 32 bits set to all 1s.  Needless to say, attempting to copy that rx_opaque did not end well.
[14:22:24] <meffie> ug.
[14:22:28] <kaduk> The only solution I'm coming up with is to switch the length field of struct rx_opaque to be explicitly u_int or afs_uint32 -- getting the rxgen-emitted code to do the right thing seems pretty challenging.
[15:04:44] Simon Wilkinson joins the room
[15:05:02] <Simon Wilkinson> Ben; I have a fix for that that I'll share.
[15:05:04] <kaduk> A Simon!
[15:05:09] <Simon Wilkinson> A fleeting Simon
[15:05:13] <kaduk> :)
[15:05:53] <Simon Wilkinson> I just need to figure out how much work is involve to disentangle it from the YFS build system
[15:06:05] <kaduk> Okay.
[15:06:29] <kaduk> It only becomes relevant when we're using rx opaques for storing non-XDR data, though, since XDR is limited to the 32-bit length field...
[15:06:54] <kaduk> (Rather, the desire for size_t instead of afs_uint32 only becomes an issue)
[15:07:31] <Simon Wilkinson> Yeah, but having size_t there makes it much easier to safely share rx_opaque values with other things without getting data loss warnings
[15:08:02] <kaduk> Also true.
[15:08:31] <kaduk> My current build gets quite a pile of warnings, starting as it is with clang -Weverything and silencing things that cause the build to fail.  CFLAGS is 6 or eight lines...
[15:09:07] <Simon Wilkinson> I don't think we'll ever be -Weverything safe, because signed vs unsigned is such a mess
[15:09:12] <Simon Wilkinson> You can't even write() without casts
[15:09:15] <kaduk> Yeah.
[15:09:51] <kaduk> I think I still have sign-compare on, but only pay attention to it for new code.  And even then, I may still just decide to ignore some of them.
[15:10:08] <kaduk> Also, trying to use any type narrower than 'int' requires a lot of casts.
[15:11:07] <Simon Wilkinson> As I said to Mark when he brought this up last, I think the best thing to do is to create specific types for things which you have to be cautious about the sign of (vnodes, for example), using structs so the compiler doesn't helpfully promote stuff for you.
[15:11:39] <kaduk> *nods*
[15:20:56] <kaduk> Apparently -Weverything is not very commonly used, though -- I tripped over a clang bug in -Wconsumed's implementation that caused clang to crash.
[15:21:29] Simon Wilkinson leaves the room
[15:37:39] <kaduk> Debian says that jessie will have kernel 3.16.
[15:42:07] Jeffrey Altman leaves the room
[15:42:15] Jeffrey Altman joins the room
[16:02:00] <wiesand> And since noone runs debian stable, this means we'll better have a release supporting 3.16 rather soon. I asked for a 1.6.9.x branch...
[16:03:44] <kaduk> The debian machine I use the most is running unstable, actually...
[16:04:47] meffie leaves the room
[16:08:10] <wiesand> Looks like we'll have a real meeting next week, with an invitation and an agenda.
[16:08:58] <wiesand> Thanks for being here today. Bye.
[16:09:01] wiesand leaves the room
[16:10:15] Marc Dionne leaves the room
[17:47:41] stephan.wiesand joins the room
[17:52:42] stephan.wiesand leaves the room
[21:11:35] kaduk leaves the room
[21:32:32] kaduk joins the room
[22:45:36] kaduk leaves the room