[02:24:12] --- manfred furuholmen has become available [02:31:36] --- stevegt has left: Replaced by new connection [02:31:37] --- stevegt has become available [02:58:53] --- Russ has left: Disconnected [03:45:29] --- manfred furuholmen has left [03:49:46] --- stevegt has left: Lost connection [03:49:46] --- dev-zero@jabber.org has left: Lost connection [04:18:47] --- manfred furuholmen has become available [04:20:55] --- abo has left [04:21:47] --- stevegt has become available [04:25:30] --- dev-zero@jabber.org has become available [04:47:57] --- manfred furuholmen has left [05:12:35] i guess no jake [05:16:19] ah, i see, i missed the "not meeting" [05:25:41] --- abo has become available [06:18:18] --- stevenjenkins has become available [06:45:24] derrick, yep. sitemap is up though, if you want [06:47:45] --- dmontuori has become available [06:52:30] --- manfred furuholmen has become available [07:18:41] --- dragos.tatulea has become available [07:18:47] hi [07:19:16] hi dragos [07:24:51] am I still here? [07:32:33] yes [07:34:52] okay [07:35:47] solaris cm patch for review. /afs/andrew.cmu.edu/usr/shadow/solaris.diff no functional changes. just protoizes osi_vnodeops.c, removes one unused function, and adds real prototypes for gafs_* functions instead of the forward decls we had. [07:36:37] shadow: >I do think there needs to be some work probing refcounts via cmdebug to confirm that the right thing happens, since as nearly as I can see, it doesn't. [07:36:54] what do you mean? [07:38:59] you increment refcounts as you put things on the dirty list. do the right number of decrements happen later? [07:44:51] yes [07:45:31] I decrement the refcount on reconnection [07:45:42] when they get sync'ed with the server [07:47:05] --- dmontuori has left [07:47:11] --- dmontuori has become available [07:47:28] What would be the corner cases? [07:49:46] Besides that, have a question about pinning. I need a way to keep the list of pinned files. I could do that in the kernel by linking the vnodes in a list. Or I could do it in userspace but what is the component that could keep this information? [07:59:15] what happens if the replay fails? do things ever stay in the dirty list after reconnect? [07:59:30] pinned: i'd do it in the kernel [08:02:41] >do things ever stay in the dirty list after reconnect? yes [08:03:20] >pinned: i'd do it in the kernel. How does my proposed method sound? [08:05:30] as long as you have a way to store it, fine. you might need a file to page it out to, like the CacheItems file, depending how you do it [08:15:42] well...I was thinking of Simons implementation of storing vcaches to disk on shutdown [08:16:34] on restart, I can walk the vcaches and add them to the pinned list when encountering the pin flag [08:16:51] I have to run now. Need to catch the train. Bye. [08:16:55] --- dragos.tatulea has left [08:41:27] --- SecureEndpoints has left: Replaced by new connection [08:52:41] --- reuteras has left [09:02:41] --- dev-zero@jabber.org has left [09:15:25] --- matt has become available [10:04:16] --- manfred furuholmen has left [10:06:43] --- stevegt has left [10:19:16] bah, no one wants to look at that diff? [10:26:17] --- mmeffie has become available [10:32:36] --- dev-zero@jabber.org has become available [10:33:22] --- SecureEndpoints has become available [10:36:45] --- summatusmentis has left [10:41:15] huh? [10:41:33] --- summatusmentis has become available [10:43:43] huh what? [10:43:49] read the backscroll... [10:44:45] what? [10:45:48] i'll take "the only message today which mentioned a patch for solaris" for $100, alex. [10:46:18] I must've missed some middle conversation [10:46:36] no. that's the point. i sent one message, and no one commented. [10:47:40] I see. Yeah, I would look at it if I knew anything about Solaris [10:47:52] good. so i'm not nuts. [10:47:59] or code review procedures, or really anything :-P [10:48:58] you may still be nuts [10:49:11] not nuts [10:49:37] although I would like some pecans [10:49:56] I just can't think about another turkey meal [10:50:32] anyway. /afs/andrew.cmu.edu/usr/shadow/solaris.diff protoizes osi_vnodeops.c and should have no functional change (other than dealing correctly with afs_inactive's return type) [10:52:49] jeff, I should make another 'fake turkey' meal :) [11:00:13] jake, when reviewing this patch, keep an eye out for parameters that have not been assigned the correct type or parameters that are no longer in the same order that they were previously in. [11:01:13] I don't feel like I know enough about the material to review it [11:01:17] I can try [11:01:43] take a look at the patch. there isn't a lot there. [11:03:44] --- stevegt has become available [11:08:19] derrick, in afs_getpage() is there a reason you changed the parameter addr from caddr_t to addr_t? [11:16:07] also are SUN56_ENV and SUN58_ENV the same? [11:16:37] probably not. looking. [11:16:50] --- Russ has become available [11:17:15] > also are SUN56_ENV and SUN58_ENV the same? no [11:18:08] putapage? [11:18:20] yes [11:18:49] No, but newer versions are treated as differences from older ones, so both AFS_SUN56_ENV and AFS_SUN58_ENV will be defined on Solaris 8, while only AFS_SUN56_ENV will be defined on Solaris 2.6 [11:19:21] you define lenp based on SUN56_ENV or not, but it looks like original code is checking based on SUN58_ENV [11:19:25] not sure if that matters or not [11:19:30] by define, I mean give type to [11:20:18] thank you. updated diff in place. [11:20:24] it does matter. [11:20:34] jhutz is correct but isn't answering the right question. [11:20:46] --- mmeffie has left [11:21:42] --- matt has left [11:24:05] also afs_frlock, should the type for ap in AFS_SUN59 be struct flock64 or struct flock? [11:26:02] lemme look [11:26:29] that's correct. [11:26:37] now is when the thing jeff just explained applies [11:27:08] SUN59 includes SUN58, which includes SUN57, which includes SUN56 (and so on) [11:28:06] I see [11:35:56] beyond that, looks fine to me [11:38:34] you have my approval, whatever that's worth [11:44:53] --- dlc has left [12:17:07] --- matt has become available [12:26:47] --- dwbotsch has left [12:26:57] --- Russ has left: Disconnected [12:27:23] --- dwbotsch has become available [12:36:18] --- Russ has become available [12:48:51] --- stevegt has left [12:52:01] --- stevegt has become available [13:43:32] --- manfred furuholmen has become available [14:39:56] --- dev-zero@jabber.org has left [14:56:02] --- dmontuori has left [14:59:33] --- manfred furuholmen has left [16:34:30] --- matt has left [17:34:15] --- stevegt has left [17:57:57] --- Russ has left: Disconnected [18:14:28] --- Russ has become available [19:11:20] --- stevegt has become available [21:10:16] are there logs of this? [21:11:06] --- dev-zero@jabber.org has become available [21:22:51] or, derrick/jeff, if you're around. When was the last time we met about web stuff? [21:52:48] last Tuesday [21:53:45] why didn't I have that on my calendar? [21:53:49] thanks :) [22:02:35] jeff, like... 2:30 right? [22:02:51] no, that's not right. 900 am est [22:34:42] --- dev-zero@jabber.org has left [23:05:54] --- reuteras has become available [23:45:00] --- dev-zero@jabber.org has become available