[00:46:41] --- dev-zero@jabber.org has become available [00:46:52] --- Russ has left: Disconnected [00:47:13] --- dev-zero@jabber.org has left: offline [01:42:57] --- stevenjenkins has left [01:42:58] --- stevenjenkins has become available [02:51:20] --- Simon Wilkinson has become available [05:28:03] --- Jeffrey Altman has left: Replaced by new connection [06:53:50] --- mmeffie has become available [08:35:26] --- reuteras has left [08:57:14] --- dev-zero@jabber.org has become available [08:57:15] --- dev-zero@jabber.org has left: offline [09:09:38] duping hostList in the h_Enumerate routines 'should' have no side effect [09:21:03] --- tkeiser@sinenomine.net/owl has become available [09:21:05] --- bpoliakoff has become available [09:30:43] matt: question or statement of fact? [09:35:06] This is about 124097. drh believes two threads can end up calling h_TossStuff_r on the same host, and has a defensive patch. I'm confused why it's possible for it to happen in the first place. [09:35:37] The hold mechanism (or refcount replacement) is supposed to make it impossible, is it not? [09:36:44] I guess that mechanism only works providing all of the callers use it correctly. [09:37:31] at best, though I'm worried about the idea itself, combined with our tricky locking and unlocking. But my point would be, if there is a prior cause of this bug, we need to fix the prior cause too [09:38:01] Yeh. I don't think a defensive patch is a good long term solution, if there's something actually doing the wrong thing. [09:39:45] I support defensive as a hotfix, for sure. but I was looking for feedback on whether hold shouldn't have prevented a double delete--and the text in drh prior mail makes it sound like duping hostlist is problematic, when actually it's designed to be safe [09:44:36] If it turned out that this race is real, then my preferred medium term fix is to replace holds with an (atomic) refcount, because this simplifies recursive code, and also removes an artificial limit on thread count in viced. [09:46:01] I think Derrick is also looking at the host list code at the moment too, so it's possible this is something he's examining. Or it might be a different problem entirely. Of course, I htink he's flying at the moment. [09:48:03] I gave Derrick this /afs/umich.edu/user/m/b/mbenj/Public/ithrottle.diff a couple of weeks ago, and he was reasonably positive about it, but I didn't get the sense he was ready to do anything with it. I was hoping for more feedback. [10:13:44] I hope 1.6 isn't mythical... [10:14:10] Me too, but it's far from clear how we get there from here. [10:14:22] The size of the diff from 1.4 to 1.5 is scary. [10:14:59] option 1. time travel, release 1.6 in sept 2008; option 2. bite bullet [10:15:23] heck, release it in 2007 [10:15:34] option 3. build '1.6' by cherry-picking [10:15:43] (probably implies no dafs, no disconnected) [10:16:13] that is not unreasonable, -far- preferable to stasis [10:16:57] I think Jeffrey is very keen to have a world where the distribution branches for Windows and Unix are the same - that would be the easiest way to realise that. [10:21:37] I don't know if I'm being blind, but I can't see do_signal() anywhere in the kernel sources. It's not that it's not being defined, it's that it just doesn't exist! [10:21:51] I think openafs needs its new features too, in 1.6, after all these years.... [10:22:18] Oh, I think we definitely need new features. But having some folk prepared to test those features would be nice, too ... [10:22:29] *no doubt*. [10:24:41] arch/x86/kernel/signal.c:779 [10:25:00] (if we were cherry-picking, I'd hope to pick disconnected, btw) [10:25:52] I think we need both pinning, and vcaches-saved-to-disk before disconnected can go into a stable release. [10:26:01] I was hoping to have the latter done by now, but git got in the way. [10:26:08] Of course you would. But it's largeish and not as mature as much of the older stuff, and if the gaol is to have something stable with most of the features, that probably doesn't include disconnected. [10:26:20] The time spent on git was well worth it. [10:26:30] time spent: no doubt about that, indeed [10:26:51] I quite like the idea of 1.6 being a gaol. [10:27:23] andresk: Thanks. It would appear that lxr just hates me today. [10:29:53] I haven't managed to get serious discussion started about when rxk5 could merge. I've been told we can probably merge to 1.5.x soon. I'd hoped to see that happen before now... [10:31:03] The problem is that last time I looked at the rxk5 branch, it was both rxk5 and a load of other bits that Marcus thought would be useful at the time. [10:32:45] I'd also really like to see a protocol specification that I can read, rather than having to reconstruct the protocol from the source code. [10:33:14] It does have some of that. If that's clearly the blocker, and we have a merge window, I'm pretty sure that extra stuff can dissappear. [10:33:46] I think it shouldn't be hard to document better, either. [10:33:55] For me, I think there are a few blockers. Bear in mind that I have no more say in this than you do, though! [10:34:57] I'd really like to see the protocol documented in a way that we can put it through a decent review. I'd hate to see us deploy a new security mechanism without giving it thorough design scrutiny. [10:35:34] Secondly, it's a huge chunk of new code. If we are looking to stabilise 1.5 in order to release 1.6 this year, then it would probably make sense to defer merging until 1.6 is out of the door. [10:39:46] I also regret that the rkx5 / rxgk discussion was never had in a public forum. [10:43:50] Marcus and I have been told that rxk5 is desireable -several times- over the last 3+ years. You're saying that now, again, it is not? [10:44:10] I'm not saying that it's not desirable. [10:44:22] (too many negatives in that sentence) [10:44:47] I'm saying that the community has never been involved in the discussion about the relative pros and cons of rkx5 and rxgk. [10:46:26] The problem with that statement is, it has never been necessary for the community to reject inclusion of rxk5 in order to have some other encryption mechanism. One of the strengths of rx is it's ability to support a -more than one- encryption mechanism. [10:46:41] Indeed, security mechanism more generally, within some limits. [10:47:22] Indeed. And as long as we (OpenAFS) are prepared to distribute multiple mechanisms, then this is a non-issue. [10:47:36] But after operating for years on the premise that openafs wanted to be an open source effort, in which voluntary contributions of high quality were welcome, I found that to be not so true. [10:47:59] --- Russ has become available [10:49:09] I think any _succesfull_ open source effort doesn't take every piece of code which is contributed to them. They all have some over-riding architectural strategy, and most will be reluctant to accept code that isn't in line with that strategy. In some cases, the strategy will be modified to fit with the events on the ground (bread today, and all that). [10:50:16] I think that OpenAFS can be one of two things. A project I want to continue being actively involved in, or one I do not. I have myself a great deal to contribute, but only a finite number of years in which to do so. [10:50:40] Yes, and having code sit for ages to get into the tree doesn't help anyone. [10:51:15] Voluntary contributions of high _quantity_ without any prior community involvement have never been particularly welcome. I can't speak for the quality of the rxk5 work. I do know that in talking about integration of rxgk into the AFS protocol suite, we ran into a number of issues not specific to rxgk which arise whenever you start trying to have multiple mechanisms deployed, most of which boil down to rx having very crappy security class negotiation. [10:51:58] > I can't speak for the quality of the rxk5 work. ... because I haven't reviewed the code carefully enough to have an opinion [10:53:13] I'd love to see a community discussion of how to improve the negotiation problem in a backward-compatible, security-class-independent way. Preferably after SASL finishes with GS2 and SCRAM; I really don't want to have more than one mechanism negotiation discussion at a time. [10:53:34] So, some time next decade, then? :) [10:53:53] And yet, if -you- jhutz haven't been able to make time to review rxk5 over the last 3+ years, wow. That probably goes to prove OpenAFS has a serious viability problem -as such-. [10:54:17] rxk5 has _never_ been presented in a reviewable form, that I'm aware of. [10:54:49] Oh, and rx and rxkad have been so presented? [10:55:05] They're not a major piece of new code. [10:55:12] rx and rxkad came already done [10:55:32] And actually, yeah, rx was the subject of papers 20 years ago. probably a couple of people got theses out of it. [10:56:00] --- stevenjenkins has left [10:56:43] Not that I wouldn't like to see good protocol documentation on rxkad and especially rx itself; I think that might have saved us from some of the repeated pain regarding multihomed hosts in the first couple of years. [10:58:48] See, I'm not sure I _can_ usefully review rxk5 without a protocol spec. It's much easier to get and keep interoperability, including across time within one implementation, if you start with a spec, make sure the spec says something reasonable, and then verify that an implementation meets the spec. Source code does not generally make a good protocol spec, in no small part because people fail to distinguish between fixing bugs in the code and making changes to the protocol. [10:59:57] --- stevenjenkins has become available [11:02:13] The problem is that openafs owed us the seriousness to provide reviewers, give serious and constructive feedback, and all of that, years ago. Now when we are at the finish line, it wants to move the line back 2 years. It's an unserious response to a problem that should have been solved 5+ years ago. [11:03:01] > in which voluntary contributions of high quality were welcome, I found that to be not so true. [11:03:10] name one, so we can debate what "high quality" is :) [11:03:55] Ok, take that one, in it's current form. Have the debate, present a list of issue to fix, and await changeset. [11:04:32] we can't get reviewers for minor fixes. do you think i have a box under my bed i'm not sharing? [11:04:57] The strong likelihood is there may well be protocol ideas in rxk5 that should change, in response to feedback. I don't -have any- from enough people for it to matter! [11:06:56] But "we can't get reviewers for minor fixes" is interesting. It reminds me of, we can't get gatekeepers. I have, I believe, reviewed every change I've been asked to review. It was not that many. If that leads to, we don't think you qualified, please say so. [11:07:50] so what did you have to say about the volser transaction creation retry patch? [11:07:58] because it's not in my mail or any im log [11:08:14] when was I asked to review that, derrick? [11:08:22] and that's simply the most recent patch from which i have no comments, positive or negative, from anyone, and it's simple [11:08:32] I think the scale of the rxk5 problem is the following: [11:08:37] 652 files changed, 73988 insertions(+), 9698 deletions(-) [11:08:40] you volunteered, when i complained no one was reviewing it! when did you ask yourself? [11:09:49] rainer had no comment. the people who said rainer "did it wrong" (i agreed) had no comment. no one said anything. and it's tiny! like 3 files! [11:10:10] I don't recall saying this. what is the delta? [11:10:34] well, at the time it was in rt. you asked where the patch was. i told you that. [11:11:02] So what you're saying is, I'm one of the non-contributors you have been putting up with all this time. [11:11:23] No, what he's saying is that it's really difficult to get folk to review things. [11:11:51] I'm hoping we can make that a little better with some technical improvements,. [11:11:53] what i'm saying is we're not awash in time. you me or anyone else. and you're asking for something on the scale of miracle when i can't get a drop of water from a river [11:12:14] But, that isn't going to help with rxk5, because it just isn't in a format that anyone could start reviewing it. [11:12:25] I've said this to Marcus before. I'm not saying anything new here. [11:12:26] --- stevenjenkins has left [11:12:34] you want reviewers. ok. give me a small chunk, self-contained, and i'll find reviewers. then another. then another, [11:12:38] One patch per change, one change per patch. [11:13:00] Rxk5 is going to be a large changeset, even with all extrinsic stuff remoevd. [11:13:01] And don't intermingle stuff that's for rxk5 with random other changes. [11:13:13] well, starting by removing the extrinsics would help [11:13:19] Yes. [11:13:26] It should have a protocol writeup. [11:13:36] It should. That would be a huge help in review. [11:13:43] --- abo has left [11:13:45] even if it's incomplete, having a vague idea what the goals were will help a review [11:13:52] It means that the protocol can be examined, and then the implementation checked against the protocol. [11:14:03] Right, that's clear. [11:14:18] But nobody's going to perform protocol review by extrapolating from source code. [11:15:06] It's done all the time. [11:15:29] --- stevenjenkins has become available [11:15:34] I'm not seriously arguing. [11:15:44] getting a review of any decent quality for a change on this scale *should not* be done that way, even if it could [11:16:00] Yes, wrt the protocol that's true. [11:16:47] yes, that's what i'm talking about [11:17:04] It doesn't have to be a large changeset. Give me a protocol specification for an Rx security class. Give me a patch which implements such a class. If the implementation depends on separable components like k5ssl, make that a separate patch. And a patch which add support for servers to accept rxk5 connections. Give me another patch which extends the ktc to support multiple token types. And one which specifically handles and uses rxk5 tokens And one which provides tools for setting rxk5 tokens Give me yet another patch which enables support for using rxk5 connections in user-mode clients like pts and vos. [11:17:34] jhutz: thanks for being specific. that could be done [11:17:45] starting with k5ssl as a patch, actually, could be useful [11:18:11] > It's done all the time. None of the people here with expertise in reviewing that sort of thing are going to do it in this case by extrapolating from source code. [11:18:11] like, regardless of what else, one patch which is only k5ssl. which could ship, well, mod configure issues, tomorrow [11:18:18] It's also easier to review, because it doesn't have many implications on the rest of the code. [11:18:26] Ah, Derrick got there first. [11:18:54] That's the productive discussion I was hoping for. [11:19:32] well, accusing us of parking on your code and going to sleep probably wasn't the fastest route, but we want secure rx as badly as you do [11:19:39] If you can wait a couple of weeks, I think gerrit and git could make this a lot easier from a management perspective. [11:19:53] having played with gerrit yesterday, i agree [11:20:42] But the real thing is pulling out all of the extras into their own patchsets, that can be completely independent of rxk5. [11:20:43] There is openafs workshop next week at which marcus and I will be present. It seems like some review discussion could happen in that context, if supporting material were available. [11:21:06] It could, if review happened before that time. But I think that is unlikely. [11:21:08] I think any serious review of rxk5 itself has to be done after protocol documentation is available. [11:22:06] granting this, some is going to be made available. [11:22:09] Though, many of the other pieces I described could be reviewed without rxk5 protocol documentation, though not usefully integrated. [11:22:48] I think the two main issues are specification, and splitting the patches into manageable chunks, which only contain rxk5 specific items. [11:22:57] Note, BTW, that what you'll get is review of the protocol (take that to afs3-standardization), probably with proposed changes. I for one am unlikely to look at the implementation until after we've settled on the protocol. [11:23:33] The protocol is going to get criticism. [11:24:15] And we'll have to balance possible improvements, against the benefit of having existing code. I think that's a juggling match for the afs3-stds mailing list. [11:24:19] I anticipate most of it will be of the type that says, I don't see a security issue therewith, but I would prefer to do something differently. How is that handled at that stage. [11:25:05] I meant, asking the above as a question. [11:25:05] Personally, I think it depends on a) the magnitude of the issue, and b) whether the objector is proposing to write code to implement their something different. [11:25:32] Those would be useful criteria. [11:25:57] Like, there's no point designing something perfect if it never gets built. [11:26:16] sxw +1 [11:26:28] Similarly, there's no point in rapidly shipping a new security class that's spectacularly broken. [11:26:35] small but solid steps in the right direction are good. [11:26:57] or even 'a better than where we are now' direction. [11:28:45] I doubt it's spectacularly broken, but if it is, well, it needs a rewrite. [11:31:25] rapidly shipping: um... [11:31:41] Anyways, ok, I assume this discussion is done for now? [11:32:07] I guess so. I'm happy to review code, when it's in a form that can be looked at! [11:33:50] i'm gonna finish packing and try to head toward the airport before rush hour. i'll be back online later [11:34:05] hmmm. packing. now there's an idea ... [11:44:26] thanks for comments, simon, jhutz, derrick, steven [11:44:49] --- matt has left [11:44:59] There aren't hard criteria. You can't say "well, you didn't write code, so we're ignoring your idea". The afs3-stds list will have to reach a rough consensus. [11:45:43] --- matt has become available [11:46:14] Yes, but I'd expect that consensus to be influenced by our requirement to actually ship something. [11:46:29] Which idea who ignoring? [11:47:11] No specific idea. I think jhutz is objecting to my "whether the objector is proposing to write code to implement their something different" [11:48:56] Oh, ok. [11:52:51] The thing I posted as 124886 can be reviewed. I'd like to get more eyes on GetSomeSpace_r in that. Ignore xcb bits. Assum osi_atomic_inc/dec do what you would expect. [11:53:23] matt: Do you have git? [11:53:28] Do you fancy uploading that to gerrit? [11:53:51] It exists as a git branch, yes. How can it get to gerrit? [11:54:12] Where can I privately Jabber you? [11:54:22] matt@linuxbox.com [12:33:37] simon has helped bring https://gerrit.openafs.inf.ed.ac.uk/Gerrit#change,3 into being [12:37:52] (you never saw that) [12:43:41] --- matt has left [12:45:44] --- haba has become available [12:51:11] * haba does not like travel where you have to be at certain times at certain locations (boarding times for example suck) [12:52:33] (everything looks fine, ETA SFO Sunday at 12:05) [12:57:45] haba: Agreed. I especially dislike flying, which is just an elongated version of hurry up, then wait. [12:59:48] plus the whole "i'm in a cramped aluminum tube stuffed with people, luggage and jet fuel screaming through the air" [13:01:45] Yeh. [13:08:11] Yeah, the cramped bit sucks. The "people" part leaves something to be desired, too. That, and power is virtually nonexistent and networking is priced like it's 1970, if it's available at all. [13:08:41] This is why I prefer to travel by rail when I can. It takes longer, but power is plentiful, I can use EVDO, and I have someplace to sleep. [13:10:37] I'm not sure that the transatlantic rail tunnel is progressing particularly quickly. [13:11:30] But yeh, I'd much rather travel by rail when I can. I suspect that if I go to Rome, I'll do that entirely by train. [13:11:31] Yeah, that's sort of annoying. One of these days I'm going to try transatlantic travel by ship. [13:11:45] i really want to try that some time. [13:11:53] A friend of mine did that crossing by container ship. [13:12:05] They went all round the world without flying. [13:12:12] Ok. Let's schedule the 2011 workshop on a cruise ship. [13:12:34] > They went all round the world without flying. That's like going home from work without using the parkway? [13:14:06] Like going to work without using the car, perhaps. [14:10:00] sometimes network is free when you fly, now, oddly. not for me, but, well, i have shit i need to do, so flight it is [14:18:59] Tomorrow morning my girl will be leaving to Munich and I will fly out ~24h later. A lot of packing is currently going on. [14:24:18] --- cclausen has become available [14:24:35] good night folks. [14:24:44] See you in CA1 [14:25:00] sure! When will you arrive? [14:25:33] Saturday evening. [14:25:54] Abo is flying BA and will arrive sunday evening, so you are 24h before him. [14:26:09] (I guess) [14:26:27] See you there. [14:26:41] cruiseship for 2011 does sound like a good idea. I'll totally look into doing that jhutz was actually serious [14:27:43] I was I was flying BA. Continental, sadly. [14:27:52] sadly, i'm betting that for many people (myself including), going to a boss and saying "send me to this thing. it's on a cruiseship." probably wouldn't work well. [14:28:09] I think mine might need some convincing. Or an invitation. [14:28:58] --- stevenjenkins has left [14:29:49] ah, I see [14:29:54] you have it better than me though [14:30:01] I have to take vacation to go to this conference [14:30:26] (and then pay my own way or obtain funding...) [14:32:22] --- stevenjenkins has become available [14:38:10] Fortunately work are prepared to pay for me to come to the Workshop, as long is I'm presenting. [14:38:24] I suspect if I want to go to the European conference, I'll have to do so under my own steam. [14:39:46] --- mmeffie has left [14:42:29] or diesel [14:44:46] electric, most likely. [14:45:16] diesel-electric, overhead catenary, or third-rail? [14:45:45] overhead catenary [15:06:40] workshop in pittsburgh again, but on the gateway clipper the entire time [15:40:20] --- Simon Wilkinson has left [16:15:57] --- Jeffrey Altman has become available [16:44:13] --- bpoliakoff has left [16:53:19] --- cclausen has left [17:52:55] --- Russ has left: Disconnected [18:51:21] --- Russ has become available