[00:01:12] --- Russ has left: Disconnected [00:32:44] --- Russ has become available [01:42:35] --- lars.malinowsky has become available [02:39:33] --- Russ has left: Disconnected [04:19:00] --- lars.malinowsky has left [04:23:30] --- lars.malinowsky has become available [05:31:28] --- meffie has become available [06:28:48] --- Derrick Brashear has left [06:30:21] --- Derrick Brashear has become available [06:38:42] --- Derrick Brashear has left [06:55:34] --- Simon Wilkinson has become available [07:04:42] --- Derrick Brashear has become available [07:36:47] --- deason has become available [08:31:34] --- Derrick Brashear has left [08:58:51] --- jaltman/FrogsLeap has left: Disconnected [09:01:23] --- jaltman/FrogsLeap has become available [09:11:13] --- Simon Wilkinson has left [09:16:02] --- Simon Wilkinson has become available [09:20:32] --- Simon Wilkinson has left [09:27:01] --- lars.malinowsky has left [10:09:11] --- Simon Wilkinson has become available [10:52:35] --- Simon Wilkinson has left [11:41:39] --- jaltman/FrogsLeap has left: Replaced by new connection [11:41:40] --- jaltman/FrogsLeap has become available [12:01:31] --- jaltman/FrogsLeap has left: Disconnected [12:01:40] --- jaltman/FrogsLeap has become available [12:12:12] --- jakllsch has become available [12:32:07] --- rra has become available [12:36:52] what's special about MT_CC? [12:39:00] ah, -mt for CFLAGS :P [12:39:58] i'm trying track down why SHLIB_LINKER is empty on NetBSD [12:50:17] ah, perhaps a typo [15:38:54] --- mdionne has become available [16:06:02] --- deason has left [17:07:25] --- meffie has left [17:12:42] so, the afs syscall, the arguments consist of the opcode followed by that operation's arguments? [17:14:27] That's correct for platforms that use a syscall. [17:14:33] Except for IRIX. [17:14:58] Well, and AIX, since it has a different way of doing syscalls entirely. [17:15:07] uh, okay :-) [17:15:14] The syscall stuff is really complicated. [17:15:27] Yes, but note there are two levels of that. The first argument is always an AFSCALL_*. For afsd<->CM stuff, it's AFSCALL_CALL, and the next argument is some AFSOP_*, followed by that operation's arguments. For pioctl, it's AFSCALL_PIOCTL, followed by the pioctl number, then the arguments for pioctl, which are always the same (a path, a don't-follow-links flag, and a struct ViceIoctl pointer, but not in that order) [17:15:59] We use ioctls on Linux, Mac OS X, and recent Solaris, syscall() on most other platforms, and then AIX has this weird thing where syscalls are available to binaries via external linkage so it's a little different, and IRIX actually allocated a bunch of syscall numbers for us, IIRC. [17:16:08] The i* operations used on inode-fileserver platforms are their own top-level opcodes, and so it... setpag, IIRC. On some (old) platforms, setpag is its own syscall. [17:16:40] hmm, i suppose i would need to look at how the Arla implementation worked then [17:16:58] Generally I think it does the same thing. [17:17:16] But that's just from some brief looking. [17:17:48] well, yeah. the idea is to have openafs act exactly like arla did so userland doesn't have to change :-) [17:17:52] Yes, Irix is wierd because SGI people did the port. AIX is wierd just because that's how syscalls work on AIX. And yes, on some platforms, we do the ioctl thing. What happens there is that there's some magic device somewhere that you do an ioctl(2) on, with an ioctl op that means "AFS system call", and the ioctl argument is a pointer to a structure that contains all the things that would normally have been the arguments to the AFS syscall. [17:18:14] Well, it's a magic device on some platforms; on Linux it's a magic file in /proc. But same idea. [17:18:30] Arla does the same things; the setpag and pioctl interfaces are intended to interoperate, modulo private pioctl numbers. [17:18:44] Oh, yes; I forgot the magic /proc file is in fact not a device. [17:19:05] This is why it was so much fun to write my own kafs layer for pam-afs-session. :) [17:19:20] WAYRTTD [17:19:52] I suspect "implement the AFS syscall layer on NetBSD" given previous questions. [17:20:46] Hrm. I thought we had that already. [17:21:08] In the grand tradition of the AFS syscall implementation, you should do something completely differentn than every other platform. [17:21:10] I suggest using doors. [17:21:18] we do, i was just looking over compiler warnings in that area [17:21:26] Does netbsd even have doors? [17:21:29] Oh, okay. [17:21:32] Probably not; they're a System V thing. [17:21:34] what are doors? :-) [17:21:45] An IPC mechanism. [17:21:45] not that i need to know or anything [17:22:01] Well, a streams thing, I should say. Sort of. I never could figure out their exact heritage. Solaris used them heavily (at least once upon a time). [17:23:30] In fact, an almost RPC-like IPC mechanism, with rendesvous via a new kind of special file. Clients open that file somehow, call door_call(), and the call is handled in the server, where the door mechanism (with kernel assist) automatically manages threads to handle each call. While a call is being processed, the client blocks, and the server gets to know some things about it and do some manipulation of its address space. [17:23:40] They were sort of a replacement for UNIX domain sockets that made some things a lot easier. [17:24:27] Solaris uses them heavily, present tense. I was under the impression they came from Sun, but maybe there is some other magical SysV upstream that still existed when they were introduced, around Solaris 7 or so (they weren't documented until later, but nscd used them quite early) [17:24:51] I could have sworn that I saw them on some other SysV-derived system. HP-UX or something. But I could be making that up. [17:25:05] I see there's an implementation for Linux, but it's pretty dated. [17:25:33] It might have just been purely a Sun thing. [17:27:37] I've always gotten the impression that Sun was the only major SysV vendor to really embrace new SysV features, while everyone else just privately wished they'd stayed BSD. [17:27:50] Yeah, likewise. [17:28:06] They went for streams in a really big way for a while, for instance, and everyone else still mostly embraced sockets. [17:28:37] Of course, given how that went, that may be one of the reasons why everyone else continued to privately wish they'd just stayed with BSD. :) [17:28:51] The short time period where Solaris yanked index and bcopy from libc was fun too. [17:29:17] I patched a *lot* of free software. [17:29:47] Well, sort of. Sun actually embraced sockets, too, even in those days, because actually _doing_ everything as if the streams abstractions were real was just a nightmare. So in practice, not only was the sockets API a layer above assembling streams, but if you assembled a stream just write, then the kernel short-circuited everything in favor of a more traditional model that actually had good performance. [17:30:17] Eventually they gave in and got rid of the intermediate layers, IIRC [17:30:33] INN still has somewhat neat code that uses streams. [17:31:40] > I patched a *lot* of free software. We added -lbsdcompat to the link lines of a lot of software. :-) [17:31:59] Yeah, but converting to ISO C was more correct, and I was a student who was bored. :) [17:32:11] We fed back a bunch of patches. [17:32:20] You seem to bore easily. I guess I shouldn't complain about that. :-) [17:32:27] INN's problem is that innd, which is running as the news user, wants to bind to a privileged port. [17:32:49] Originally you started innd with a setuid helper program that bound the socket and then setuid and exec innd, but that was annoying. [17:33:18] So instead I wrote a setuid helper program that takes a file descriptor number as an argument and binds to the right port for you. [17:33:52] On BSD socket-based systems, this works; the child can see and bind the parent's unbound socket and the parent can then use it. [17:34:15] On streams-based systems, it doesn't work; the child can't bind the inherited unbound socket. [17:34:35] So innbind in INN tries to bind the socket, and if that fails, it creates a new file descriptor, binds it, and passes it back to the parent via streams file descriptor passing. [17:34:55] Only time in my life I've ever had to use streams. :) [17:37:43] Wow. I'm sort of amazed having the child bind the parent's socket worked. That sort of thing really shouldn't be allowed. [17:38:06] Yeah, it's kind of funky, isn't it? [17:38:17] Once upon a time I stared at Stevens long enough to convince myself I understood why it worked. [17:40:06] It turns out that even with streams systems, you can bind your parent's socket, but the fact that the socket was created by an unprivileged process is "remembered" so you can't bind it to a low-numbered port. [17:40:19] Hm? It works because there's a distinction between an fd and an open file, and the socket operations act on the latter. [17:40:37] Yeah. [17:41:21] And, well, it sort of has to work that way, so that the right thing happens when you bind, listen, and then fork a dozen times. [17:41:52] But it seems like certain operations ought to either be prohibited or result in duping the file [17:41:54] Yeah. So the same thing lets you also bind the inherited sockets and have that affect everyone who has an open fd to the same file. [17:42:36] I'll be very unhappy if it stops working and I have to find some other way to do it, since the only other way right now requires streams. :) [17:43:23] I don't think there's a way to pass file descriptors via standard output on BSD systems; I'd have to create a UNIX domain socket or something. [17:49:47] Hrm. Yeah, you can pass fd's via unix-domain sockets, but... socketpair() ? [17:50:07] Oh, yeah, that would probably work. [17:50:11] I didn't think of that. [17:50:41] socketpair should cover everything that doesn't have streams pretty safely. [17:53:24] Today, yes. When you wrote it, the fd-passing stuff may not have been there. [17:53:57] Yeah, I don't recall. I tried just binding in the child first and discovered it worked, so didn't explore the alternatives except on SysV. [17:54:21] I think I considered using a UNIX domain socket but didn't because that wouldn't have worked on all the SysV systems, and then found streams fd passing, which filled exactly the gap of my problem platforms. [18:37:39] --- deason has become available [18:45:16] --- mdionne has left [21:21:05] --- deason has left [21:32:32] fun, the rijndael[AEK]* functions are already in the kernel [21:32:58] err, DEK [21:39:27] --- steven.jenkins has left [23:47:14] --- rra has left: Disconnected