[04:14:22] --- mvita has become available [04:30:33] --- mvita has left [05:00:11] --- Marc Dionne has become available [05:33:08] --- mvita has become available [07:45:41] --- ballbery has left [07:46:21] --- deason has become available [07:52:26] --- ballbery has become available [08:17:58] Will gerrit refuse to accept a merge commit? [08:18:27] It should do, yes [08:18:53] Just checking, thanks. [08:19:28] I want to push some rxgk bits and some rxgk-bos bits to gerrit to get started on review (well, I will do some more fixups, first), but the rxgk-bos bits depend on pthreaded-bos which is ongoing in a different set of changes. [08:19:46] My current plan is to snapshot the pthread-bos series and squash it down to a single commit that is used as a placeholder instead of a merge commit. [08:20:15] That would be one option. You'll end up with that placeholder in gerrit, though [08:20:22] Right. [08:20:26] And I think OpenAFS's gerrit is too old to support drafts. [08:20:50] The other options involve rebasing either rxgk or pthread-bos on top of the other, which is likely to end up being annoying. [08:21:07] Yeah, especially if you have to keep changing both patchsets. [08:21:38] The logical order in my mind is something like: rxgk and pthread-bos are independent. Get them in, get them reviewed [08:21:52] Then push rxgk-bos on top of a tree once both of those are merged [08:22:12] If rxgk needs context to be understandable, then provide that context with a test suite, rather than with rxgk-bos [08:23:15] At least some of why I want to put rxgk-bos into gerrit is to get people started thinking about (well, I'm sure you have already thought about these things; other people) the changes to core infrastructure that will be needed to bring rxgk support into other parts of the tree. [08:23:29] I suppose that doesn't necessarily need to be done in gerrit, though. [08:23:54] I thought I'd pushed pretty much all of the core infrastructure changes that were required. [08:24:12] Basically, whilst YFS was grant funded, I pushed everything but the bits that required standardisation [08:24:14] You have certainly done a huge amount of behind-the-scenes work to support it, yes. [08:24:44] And the whole idea of the security layer abstraction is that you _shouldn't_ have to change lots of APIs to add a new security layer [08:25:10] But, say, BuildServerSecurityObjects will need to know what token-encrypting key to use and what gss acceptor identity to use; PickClientSecurityObject will need to know what GSS acceptor and host to target. [08:25:33] Maybe that's not quite "core". [08:25:43] But still, useful library interfaces. [08:32:14] Yeah, afsconf gets interesting [08:50:19] --- mvita has left [09:15:38] --- mvita has become available [09:17:17] --- mvita has left [13:20:25] --- jaltman/FrogsLeap has left: Disconnected [13:52:04] --- jaltman/FrogsLeap has become available [15:10:12] Looks like I got a bit overzealous in converting RXGK_Datas to rx_opaques -- I cannot use rx_opaque_freeContents to free the output parameter of an RPC, when that parameter is zero-length, apparently. xdr_free((xdrproc_t)xdr_RXGK_Data,.) does the right thing, though. [15:11:14] More importantly, if the memory has been allocated with xdr_alloc, it must be freed with xdr_free [15:11:27] Otherwise Windows will hate you. Or something. [15:12:03] I thought Jeff says we're using roken everywhere always, so it's actually okay now. But I could be misremembering. [15:12:37] I suppose this means things should get better commented during review about what to free things with. I've been switching most things I allocate explicitly to rxi_Alloc from xdr_alloc. [15:13:31] Any thoughts about where to document the extended UserList format? I got it wrong a couple times before I got things working :) [15:14:08] I can't remember whether OpenAFS has got rid of all of the places where we would use the operating system's own XDR [15:14:26] In those cases, you need to be correct about where you malloc, where you xdr_alloc, and where you rxi_Alloc [15:14:57] Definitely. [15:16:04] I'm a little confused at how my opaque RPC output parameter ended up with a non-NULL .val given that it was NULL on input, but do not feel like tracing through the en/decoder today. [15:16:11] WRT the UserList, it should probably have a manpage. The format was designed so that it is externally modifiable, for those folk who want to use configuration management systems [15:16:32] One of the allocators returns a pointer to a specific memory location if you try to allocate zero bytes. [15:17:26] I think this one would be going through xdr_RXGK_Data, which has a max length, so maybe it would allocate that length upon seeing NULL? As I say, not tracing through it today. [15:27:14] xdr_alloc calls osi_alloc which returns memZero if you ask it to allocate zero length. You need to call osi_free to avoid blowing up. [15:27:59] (it also means that you can only safely detect zero length from the length, you can't compare the pointer to NULL) [15:28:31] OpenAFS on Windows uses roken's allocator which means that we do not crash when DLLs built with mixed allocators are used together. I did that because I got tired of chasing all of the places where things are done wrong. Memory should be freed by the subsystem that allocates it. If at some point a module is built with a debugging allocator or something it shouldn't result in crashes. [15:30:24] Right. [15:30:26] RX is probably the only place left where you do need to get it right to avoid crashing, because of the memZero case [15:30:40] I tried to be consistent, but am changing some things around at the last minute, and will probably mess up somewhere. [15:31:06] --- deason has left [18:57:34] --- mvita has become available [19:48:28] --- mvita has left