[00:22:58] --- haba has become available [00:45:47] --- kaj has become available [01:22:58] --- Russ has left: Disconnected [02:47:42] --- reuteras has become available [02:56:45] --- haba has left [03:12:16] --- Simon Wilkinson has become available [03:35:37] --- Simon Wilkinson has left [03:37:14] --- Simon Wilkinson has become available [03:37:49] kaduk: That cast looks decidely iffy. [03:47:30] --- Jeffrey Altman has left: Replaced by new connection [03:48:01] --- jaltman has left: Replaced by new connection [03:48:03] --- jaltman has become available [03:53:50] --- haba has become available [04:08:37] --- Simon Wilkinson has left [04:48:51] --- abo has left [05:48:53] --- meffie has become available [07:03:02] --- Simon Wilkinson has become available [07:05:13] --- reuteras has left [07:09:11] --- deason has become available [08:26:30] Well, yes! I still don't really understand how generic userland enters the afs syscall, though, but I suspect that userland is passing in a thread* which we are treating as a proc* in some/most cases. I originally thought that this was masked by (implicitly) casting through long as an argument to afs3_syscall, but it looks like my memory was in error. [08:28:07] It would appear to enter through afs3_syscall - which is added to the syscall table in afs_init (in FBSD/osi_vfsops.c) [08:28:30] The question is what FBSD calls its syscall handlers with. [08:29:40] If AFS_FBSD_ENV is defined, that would appear to be (struct thread *, void *, long *) [08:29:51] (for AFS_FBSD50_ENV, anyway) [08:30:18] > It would appear to enter through afs3_syscall [08:30:25] i thought i said that. did i fail? [08:30:51] Not aware of fail. Just didn't see you say that. [08:31:18] Crickey, afs3_syscall is impossible to read. [08:31:31] sadly, yes. we need an osi version [08:50:18] --- Simon Wilkinson has left [08:56:10] --- deason has left [08:56:40] > enter through afs3_syscall Yes; what I don't understand is what FBSD calls its syscall handlers with, and to a lesser extent, where those calls happen. (The "design and implementation" book is surprisingly unhelpful on this front.) [08:57:30] > impossible to read And it's probably going to have to get worse to fix FBSD(50). I seem to recall that we have been removing pre-FBSD50 code, though. [08:57:43] well, um. i should check out a copy of freebsd source i guess [08:57:57] is there a premade ~recent vm of freebsd 8-current somewhere i can grab? [08:59:55] --- deason has become available [09:06:12] --- Simon Wilkinson has become available [09:06:33] --- Simon Wilkinson has left [09:06:40] --- Simon Wilkinson has become available [09:07:04] kaduk / shadow: The problem is pretty clear, I think [09:07:14] afs_setpag() behaves as if it's been passed a proc, not a thread. [09:09:08] Right. [09:09:24] It's clear that there's a lot of wrong code right now. [09:09:51] My original comment was idly pondering whether that wrong code had the potential to cause some weird side effects that I had been seeing. [09:10:02] quite possibly [09:10:25] my vm question stands [09:10:31] Yeh. The code at the moment will be using a random memory location as the credentials structure. That way lies ruin. [09:11:11] and the wakeup code tries to hint at who to wake up. similar issue [09:15:09] shadow: I don't know of a handy VM image. I have a machine on SIPB's XVM that's running a truly ancient 8-current (like, two years old), since new kernels interact poorly with the Xen environment they're using. (I haven't had time to track down exactly what broke it.) That VM is too old to be useful for us, I think -- it doesn't have some of the changes that we have assumed made it into FBSD80. [09:15:43] yeah. ok [09:15:46] also, no xen on macos, so, useless to me [09:18:34] shadow: http://www.thoughtpolice.co.uk/vmware/#freebsd8.0 [09:18:47] I expect most of the work on this front to be pretty mechanical, though; I should be able to get to it this week if you have better things to do with your time. [09:19:13] Derrick likes doing other people's work, though :) [09:20:35] I certainly won't complain too loudly if he does :) [09:23:40] you can keep working. i still want to see what's up here, and try to do better about not breaking it [09:24:07] you're just snarking because i started to write pinning [09:24:19] Not snarking at all. Glad someone got to ti. [09:25:06] kaduk: How many compiler warnings are you seeing? I suspect we're swapping types all over the place, and the compiler should notice. [09:27:08] Not too many. Actually, much of the changes I've pushed so far have been things I noticed due to compiler warnings. [09:28:07] There are a few places where it complains about different-signed pointer types, and it doesn't like the bozolocks, but I think I've fixed (or at least "fixed") (almost) all of the "initializing with incompatible pointer type" errors and friends. [09:29:01] In that case, I suspect it's worth looking for places where ill-advised pointer casts are being performed. [09:30:03] Though I should note that in the version I'm running, some clever person decided to remove the part of afs3_syscall where 'p' was defined to be a struct thread *. [09:30:25] So, possibly less useful. [09:31:06] I'm currently sitting in a room with Robert Watson, maybe I should just bug him. [09:31:26] it's not his fault [09:35:06] kaduk - just looked at fxr.watson.org [09:35:24] fxr.watson.org rocks. but he needs more xnus in it [09:36:21] On FreeBSD 8.0 a syscall gets a struct thread *, and a pointer to an array of function arguments. [09:36:47] So, find whoever removed the definition of 'p' as struct thread * and administer suitable vengeance. [09:37:35] git annotate [09:38:04] I think it's in ports, not our tree. [09:40:43] Yeah, it's in the ports version. I *think* that once the proc->thread conversion is done, our tree should be runnable. [09:41:05] ==derrick on not robert's fault "but you could bug him to put more xnu's on fxr.watson.org if you like" [09:41:23] Also, I should relocate to work. [09:41:44] But let me put my build log somewhere useful before I shut off my laptop. [09:41:52] also your patch [09:42:24] Which patch? [09:42:50] you have no code changes? [09:44:34] code changes from what to what? I have a couple unpushed changes in my git repo, but those are tiny things, unrelated to proc vs. thread [09:44:45] ok [09:46:45] I guess that /afs/sipb.mit.edu/user/kaduk/freebsd/openafs/openafs.shar.txt is pretty close to what I'm running, if that's your question. (What I'm actually running has a bunch of hacks to use curthread instead of the provided (struct proc*) argument.) [09:46:57] Anyway, gone for ten [09:48:41] --- kaj has left [09:51:03] --- kaj has become available [10:26:13] --- kaj has left [10:41:35] --- Simon Wilkinson has left [10:45:39] --- Simon Wilkinson has become available [10:47:11] --- Simon Wilkinson has left [10:54:14] --- haba has left [11:12:43] --- Russ has become available [11:33:23] --- jaltman has left: Disconnected [11:33:44] --- meffie has left [11:40:32] --- jaltman has become available [11:41:48] --- kaj has become available [12:33:44] --- meffie has become available [13:16:37] --- dwbotsch has left [13:18:28] --- dwbotsch has become available [14:05:37] --- jaltman has left: Disconnected [14:15:52] --- jaltman has become available [14:22:33] > check out a copy of freebsd source I guess Hm, I was going to put such a thing in AFS at some point, wasn't I ... maybe I should get on that. [14:23:12] Relatedly, is there an (unzipped) copy of openafs source in AFS. web interfaces are okay for some things, but grep is hard. [14:27:09] --- Russ has left: Disconnected [14:28:56] --- Russ has become available [14:46:31] (Starking) oh, right, and I get build warnings about XDR :) [14:52:44] But yeah, it does complain about assignment from incompatible pointer type where we assign afs3_syscall to the syscall table. [15:06:06] --- mdionne has become available [17:19:19] --- dev-zero@jabber.org has become available [17:31:40] --- dev-zero@jabber.org has left [17:58:22] --- meffie has left [18:23:52] --- mdionne has left [18:24:39] --- mdionne has become available [18:58:17] --- deason has left [19:08:14] --- dwbotsch has left [19:08:57] --- dwbotsch has become available [19:12:06] --- mdionne has left [19:26:13] Hm, I'm beginning to like this "treat pags like AIX" thing, what with it's avoidance of afs_GCPAGs ... [19:45:13] well, you can't entirely avoid GCPAGs. [19:45:57] I guess it's not too bad; I really want to walk threads, not procs (I think), so I get to TAILQ_FOREACH within the LIST_FOREACH [21:31:50] --- jaltman has left: Disconnected [21:34:50] --- jaltman has become available [22:05:21] --- shadow@gmail.com/owl6A7594E8 has left [22:05:59] --- shadow@gmail.com/owl5358EA64 has become available [22:08:40] --- deason has become available [22:22:16] --- deason has left [23:11:37] --- cudave has left: Disconnected [23:12:02] --- cudave has become available [23:14:40] --- reuteras has become available [23:16:29] --- kula has left [23:22:30] --- kaj has left [23:48:27] --- dev-zero@jabber.org has become available [23:49:54] --- phalenor has left